Problems with l4linux

[Adam Lackorzynski]

On Tue Oct 28, 2008 at 02:53:27 +1200, Valery V. Sedletski wrote:
> On Mon, 27 Oct 2008 01:06:43 +0100, Adam Lackorzynski wrote:
> 
> >
> >On Thu Oct 23, 2008 at 21:54:08 +1300, Valery V. Sedletski wrote:
> >> On Wed, 22 Oct 2008 19:12:59 +0200, Adam Lackorzynski wrote:
> >> 
> >> ...skipped...
> >> 
> >> So, this is iret instruction somewhere on return from a syscall, if I understood correctly.
> >> Maybe, my Fiasco config is wrong?
> >
> >Rather not. Can you tell me at which position the f.2 is in user-land?
> >That would be interesting.
> > 
> 
> This is the result of executing "tf.2" in kernel debugger:
> 
> thread:   f.02 <001e0801>               prio: a0  mcp: ff  mode: Con
> state: 001 ready    %dl
> 001e0804     into
> wait for:           polling:            rcv descr:
> lcked by: ---.--                        timeout  :
> cpu time:   2.000 ms                    timeslice: 4000/10000 µs
> pager   :   f.00        cap: ---.--     utcb: ffe34200
> preemptr:   0.00        not monitored   ready lnk:  ???.??   5.00
>                                         prsnt lnk:   f.04   f.00
> EAX=00000000  ESI=001e0801  DS=0023
> EBX=a0051454  EDI=00000000  ES=0023     iret
> ECX=0000000d  EBP=afeffe40  GS=0043     lea    0x0(%esi),%esi
> EDX=afeffe58  ESP=c03c17ec  SS=0010
> trap 13 (General Protection), error 00000070, from kernel mode
> CS=0008  EIP=f003622b  EFlags=00203246
> 001e0815     cli
> c03c17ec f003622b 00000008 00203246 [eacff102] 00000073 00203296 afeffe00 0000007b
> 001e0818     into
> 
> the [eacff102] dword was highlighted in backtrace. So, as I understood
> this, this marks current stack frame. Here we see that previous stack
> frame is ip=0xf003622b, cs=0x8, eflags=0x00203246 is respectively ip,
> cs and eflags taken off from the stack by previous iret instruction.
> Current iret must take off the next frame: eip=0xeacff102, cs=0x73,
> eflags=0x00203296. Here we can see that selector cs=0x73 is ring3 and
> eip is 0xeacff102. 

Yep, ok, cs value is bogus. Now we need to find out why, cs should be
1b. (8 is kernel code, so ok.) Maybe I find the time to reproduce this
but on the other side it does not happen when the IOPL3 option is off,
right?
 
> And also, unassembly at eip=0xeacff102:
> 
> eacff100     int    $0x31
> eacff102     ret
> 
> -- An entering the syscall?

Yes, this is from the syscall page (kernel entry code is there).

> <001e0801> -- What is it? If it is an address from where int 0x32 is
> called then instructions at this

> an address 001e0800 (into) is not in CS segment of vmlinux executable
> (no such address in objdump output) So, what is it? Corrupt stack? Or
> it is not a return address but something different?

It's the thread-ID, so nothing to disassemble :)

> >X is very demanding wrt permissions. More recent version should behave
> >better though.
> >
> >> And the question: what does cli instruction do? I guess this must trigger an I/O page fault for I/O
> >> pages to be mapped? Am I right? 
> >
> >CLI disables interrupts. Allowing this in user-land is a major security
> >breach.
> >
> 
> I know. But in ioport.c you do CLI and then STI immediately. What it does?

It tries to find out the IOPL, which only works if the option in the
kernel is enabled. That's why it was commented out.

> >> >I guess not. Which address? Anyway, I guess it should ioremap those...
> >> >
> ....
> >
> >Some of those addresses are quite low but unfortunately I don't have an
> >idea what they're used for.
> >
> 
> The Cardbus controller uses these addresses, according to windows Device manager: 
> 
> 0xb8008000-0xb8008fff
> 0xfebff000-0xfebfffff
> 0xfabff000-0xfebfefff
> 0x000db000-0x000dbfff
> 
> and modem itself uses none, only i/o and irq
> 
> Also, I searched logs and found that piece:
> 
> Oct 21 04:54:14 localhost kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
> Oct 21 04:54:14 localhost kernel: cs: memory probe 0xb8000000-0xb80fffff:__l4x_ioremap: Requested region at b8010000 [0x1000 
> Bytes]
> Oct 21 04:54:14 localhost kernel: cs: memory probe 0x70000000-0x700fffff: excluding 0x70000000-0x700fffff
> Oct 21 04:54:14 localhost kernel: cs: warning: no high memory space available!
> 
> (This was in the log with info level (there are also error and warning levels)), so, as I understood, this is not fatal.
> Also here are ioremaps, so, they are present.

Looks like this stuff is doing someting quite special, at least when
looking at the code that is producing those log lines. I fear it's not
easily doable to get this going.


Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/