Invalid Opcode on ia32, Pistachio 0.4

[Alexander Wieder]

Hi!

I'm trying to understand the handling of the invalid opcode exception on
ia32. In particular, I wonder in which cases the handler
(/source/kernel/src/glue/v4-ia32/exception.cc, L.211 et seq.) will send
an exception-IPC to the exception-handler-thread (if existent).

The code there reads as follows:

221     if (space->is_user_area(addr))
222     {
223         switch(space->get_from_user(addr))
224         {
225         case 0xf0: /* lock prefix */
226             if (space->get_from_user(addr_offset(addr, 1)) == 0x90)
227             {
228                 /* lock; nop */
229                 frame->eax =
(u32_t)space->get_kip_page_area().get_base();
230                 frame->ecx = get_kip()->api_version;
231                 frame->edx = get_kip()->api_flags;
232                 frame->esi =
get_kip()->get_kernel_descriptor()->kernel_id.get_raw();
233                 frame->eip+= 2;
234                 return;
235             }
236         default:
237             printf("invalid opcode  at IP %p\n", addr);
238             enter_kdebug("invalid opcode");
239         }
240     }
241
242     if (send_exception_ipc(frame, IA32_EXC_INVALIDOPCODE))
243         return;

This looks to me like any invalid opcode in the user area (except the
sequence lock; nop;) will execute enter_kdebug() and thus basicly crash.
By this, the exception-IPC will only be sent if the invalid opcode was
executed _not_ in user area.
Does this make sense? Wouldn't it make more sense to skip the
enter_kdebug() in L.238 (comment out) to sent the exception-IPC if the
exception was not caused by the KIP-syscall?

Any hints appreciated..


Best regards,

Alexander Wieder

[Espen Skoglund]

[Alexander Wieder]
> This looks to me like any invalid opcode in the user area (except
> the sequence lock; nop;) will execute enter_kdebug() and thus
> basicly crash.  By this, the exception-IPC will only be sent if the
> invalid opcode was executed _not_ in user area.

> Does this make sense? Wouldn't it make more sense to skip the
> enter_kdebug() in L.238 (comment out) to sent the exception-IPC if
> the exception was not caused by the KIP-syscall?

Your observation is correct.  The kernel will indeed enter kdebug upon
invalid opcode exceptions.  As I mentioned in another mail some time
ago (can't remember exactly when, must have been a month or two ago)
we currently don't always send an exception IPC upon unhandled
user-level exceptions.  This is purely due to "laziness" and
implement-whenever-needed-syndorme on the developer side (and also to
ease debugging when, e.g., doing paravirtualized Linux).  As the spec
says, the kernel is supposed to send exception IPCs when it does not
handle the exception internally.

        eSk

[Alexander Wieder]

Alexander Wieder wrote:
> Does this make sense? Wouldn't it make more sense to skip the
> enter_kdebug() in L.238 (comment out) to sent the exception-IPC if the
> exception was not caused by the KIP-syscall?
Or even better:
1. remove enter_kdebug() from L.238
2. enter_kdebug() if the exception was _not_ caused in the user area:

221     if (space->is_user_area(addr))
222     {
                [...]
240     }
241 else
242  enter_kdebug("invalid opcode");

3. remaining code is left unchanged

By this, an exception-IPC would be sent iff the faulting opcode a) is
not the sequence "lock; nop;" and b) it was executed in the user area.
Invalid opcodes outside the user area would cause enter_kdebug() to be
executed.
Would make more sense to me...


Best regards,

Alexander Wieder

[Sebastian Reichelt-2]

> Your observation is correct.  The kernel will indeed enter kdebug upon
> invalid opcode exceptions.

In case the kernel debugger is not compiled in, won't enter_kdebug() return immediately? I believe you cannot enable it in (potential) production systems anyway because any user-level program can execute L4_KDB_Enter. I may be overlooking something, though.

By the way, the same issue exists with user-level code touching the kernel's region of the virtual address space.

--
Sebastian Reichelt

[Alexander Wieder]

Hi!

Sebastian Reichelt wrote:
> In case the kernel debugger is not compiled in, won't enter_kdebug()
> return immediately? I believe you cannot enable it in (potential)
> production systems anyway because any user-level program can execute
> L4_KDB_Enter. I may be overlooking something, though.

>From /source/kernel/include/debug.h:

65 #if defined(CONFIG_DEBUG)

        [...]

118 #else /* !CONFIG_DEBUG */
119
120 /*
121  * Define all functions as empty.
122  */
123
124 # define init_console()
125 # define printf(fmt, args...)   do { } while (false)
126 # define enter_kdebug(x)        do { } while (true)
127 # define UNIMPLEMENTED()        do { } while (true)
128 # define ASSERT(x)              do { } while (false)
129 # define WARNING(fmt, args...)  do { } while (false)
130 # define TRACE(x...)            do { } while (false)
131 # define TRACEF(x...)           do { } while (false)
132 # define spin_forever(x...)     do { } while (true)
133 # define spin(x...)             do { } while (false)
134
135 #endif /* CONFIG_DEBUG */

This looks like a crash..

> By the way, the same issue exists with user-level code touching the
> kernel's region of the virtual address space.
Yeah, I noticed this, too.


Best regards,

Alexander Wieder

[Sebastian Reichelt-2]

> This looks like a crash..

Oops, you are right. I looked in arch/ia32/debug.h only, not realizing there was a different implementation.

Now (at the risk of making false assumptions again) the effect of the compilation options seems to be pretty awkward:

* If both CONFIG_DEBUG and CONFIG_KDB are set, the kernel debugger will be entered, with the option to continue normally after user input.
* If CONFIG_DEBUG is set, but CONFIG_KDB is not, nothing will happen (correct me if I am wrong).
* If neither is set, the system will crash.

--
Sebastian Reichelt

[Alexei Mandrykine]

Hello l4ka.

The code of Fast IPC path on IA32 is broken.
At least on CVS state on 2006 August 10.

I spent about two weeks to find why a signal handler does not work
correctly. The signal handler emaultes signal delivery via
L4_ExchangeRegisters syscal.

In case of receiving phase of IPC has to be aborted, application
generating strange exception - "kernel access raised user pagefault".

The reason of this exception is tcb_t::return_from_ipc(void) {glue/v4-ia32/tcb.h},
that returns to 'fp_ipc_done' {glue/v4-ia32/trap.S}. At this point ESI conveys MR0
value, but 'fp_ipc_done' uses ESI as pointer to current TCB.

This bug does not appear if kernel compiled without "Fast IPC path" feature.


--
Regards,
 Aleksey Mandrykin                         mailto:mandrookin@...

[Jan Stoess]

Thanks Alexei,

I've reproduced the bug and just corrected it in our mercurial development
repository. Find the latest version under
http://l4ka.org/projects/pistachio/download.php

--
Jan Stoess
System Architecture Group
University of Karlsruhe

> -----Original Message-----
> From: l4ka-bounces@... [mailto:l4ka-bounces@...-
> karlsruhe.de] On Behalf Of Alexei Mandrykine
> Sent: Monday, July 23, 2007 03:25
> To: l4ka@...
> Subject: Fast IPC path on IA32
>
> Hello l4ka.
>
> The code of Fast IPC path on IA32 is broken.
> At least on CVS state on 2006 August 10.
>
> I spent about two weeks to find why a signal handler does not work
> correctly. The signal handler emaultes signal delivery via
> L4_ExchangeRegisters syscal.
>
> In case of receiving phase of IPC has to be aborted, application
> generating strange exception - "kernel access raised user pagefault".
>
> The reason of this exception is tcb_t::return_from_ipc(void) {glue/v4-
> ia32/tcb.h},
> that returns to 'fp_ipc_done' {glue/v4-ia32/trap.S}. At this point ESI
> conveys MR0
> value, but 'fp_ipc_done' uses ESI as pointer to current TCB.
>
> This bug does not appear if kernel compiled without "Fast IPC path"
> feature.
>
>
> --
> Regards,
>  Aleksey Mandrykin                         mailto:mandrookin@...
>