Problems with l4linux
Valery V. Sedletski
_valerius at mail.ru
Mon Oct 27 15:53:27 CET 2008
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:
>> 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
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
c03c17ec f003622b 00000008 00203246 [eacff102] 00000073 00203296 afeffe00 0000007b
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
And also, unassembly at eip=0xeacff102:
eacff100 int $0x31
-- An entering the syscall?
<001e0801> -- What is it? If it is an address from where int 0x32 is called then instructions at this
001e07fe dec %dl
001e0802 dec %dl
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
>> 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
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:
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
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.
More information about the l4-hackers