Open Radar

 
Summary:

The Mac OS X kernel has a bug in which exceptions from the x86 "int3"
instruction are often not reported via Mach exception handling when
the %cs segment base is non-zero.

The problem does not occur when the %cs segment base is zero, nor does
it occur with other types of fault (the HLT instruction, memory access
errors, etc.).


Steps to Reproduce:

See the attached test program, mach_exception_int3_with_segs.c.


Expected Results:

The program should output something like:

Waiting for fault to be reported (with the Mac bug present, we expect this to hang)...
Got exception, type 0x6
eip=0x74465 (476261)
esp=0xc0071d5c (-1073275556)
ss=0x23 (35)
cs=0x1f (31)
ds=0x23 (35)
es=0x23 (35)
fs=0x0 (0)
gs=0xf (15)


Actual Results:

The program hangs.


Regression:

This was probably introduced when DTrace support was added to the kernel.


Notes:

When the int3 fault occurs, the Mac kernel examines the instruction
preceding %eip to check whether it is (still) an int3 instruction, but
it fails to take the %cs segment base into account.

I think I've found the code responsible in the Mac kernel sources.
xnu-1699.22.73/osfmk/i386/trap.c handles T_INT3.  It calls
dtrace_user_probe() in xnu-1699.22.73/bsd/dev/i386/dtrace_subr_x86.c,
which contains code which reads memory to check for int3.  This fails
to take the %cs segment base into account.


For the test program, see the attachment on https://code.google.com/p/nativeclient/issues/detail?id=2879