On Mon, May 04, 2009 at 03:41:16PM +0200, Manuel Bouyer wrote: > On Mon, May 04, 2009 at 11:47:29AM +0000, Andrew Doran wrote: > > Module Name: src > > Committed By: ad > > Date: Mon May 4 11:47:29 UTC 2009 > > > > Modified Files: > > src/sys/arch/i386/i386: locore.S > > > > Log Message: > > PR kern/41342: BSDi binaries cause panic > > > > XXX Manuel, please have a look as I am not sure what to do for XEN here! > > I tried the following code instead: > IDTVEC(osyscall) > CLI(%eax) # must be first instruction > pushfl # set eflags in trap frame > popl 8(%esp) > orl $PSL_I,(%esp) # re-enable ints on return to user > pushl $7 # size of instruction for restart > jmp syscall1 > > but the test binary from the PR segfaults: > truc# kdump |less > > 34 0 ktrace EMUL "netbsd" > 34 0 ktrace RET ktrace 0 > 34 0 ktrace CALL execve(0xbf7ffc02,0xbf7feb3c,0xbf7feb44) > 34 0 ktrace NAMI "./architextIndex" > 34 0 architextIndex EMUL "netbsd" > 34 0 architextIndex RET syscall JUSTRETURN > 34 0 architextIndex PSIG SIGSEGV SIG_DFL: code=SEGV_ACCERR, addr=0xacb > 94, trap=4) > 34 0 architextIndex NAMI "architextIndex.core" > > On Xen CLI(%eax) expands to: > movl CPUVAR(VCPU),%eax ; > movb $1,EVTCHN_UPCALL_MASK(%eax)
At this point the segment registers won't be set up. And %eax contains the syscall number. > I guess this is a problem. Is there a way to account for this somewhere ? It is difficult to avoid the LDT/segreg problems without having interrupts disabled instantly on entry. Maybe we could add really ugly logic to compensate for it in trap() since oosyscall is the only place where we enter with interupts on (I don't know how interrupts/traps are set up on xen currently). xen isn't as vulnerable to the LDT/segreg problem as native x86 because it's not MP and doesn't do kernel preemption. For the time being I guess it would suffice to #ifdef the 'cli'.
