Problems with l4linux

[Valery V. Sedletski]

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. 

And also, unassembly at eip=0xeacff102:

eacff100     int    $0x31
eacff102     ret

-- An entering the syscall?

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

001e07fe     dec    %dl
001e0800     into
001e0801     cli
001e0802     dec    %dl
001e0804     into
001e0805     cli

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?

>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?

>> >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.

WBR,
valery