Now
netbsd-6-1 commitmail json YAML
src/sys/arch/amd64/amd64/trap.c@1.69.2.1.6.1
/
diff
/
nxr@1.69.2.1.6.1
src/sys/arch/i386/i386/trap.c@1.262.14.1 / diff / nxr@1.262.14.1
src/sys/arch/i386/i386/trap.c@1.262.14.1 / diff / nxr@1.262.14.1
Pull up following revision(s) (requested by maxv in ticket #1446):
sys/arch/amd64/amd64/trap.c: revision 1.94
sys/arch/i386/i386/trap.c: revision 1.287
Mmh, allow iret to be handled when an #SS fault (T_STKFLT) happens. Even
if the sdm is far from being clear, it appears that iret can trigger an #SS
fault if %ss points to a writable but non-present segment; in which case
the kernel would panic, thinking the fault was internal to it.
In particular, userland can create a broken segment in the ldt with
USER_LDT, update its %ss with setcontext and trigger the panic. I don't
think amd64 is affected since USER_LDT does not exist there, and the
changes on tf_ss seem correct - but I'm still adding T_STKFLT for safety.
sys/arch/amd64/amd64/trap.c: revision 1.94
sys/arch/i386/i386/trap.c: revision 1.287
Mmh, allow iret to be handled when an #SS fault (T_STKFLT) happens. Even
if the sdm is far from being clear, it appears that iret can trigger an #SS
fault if %ss points to a writable but non-present segment; in which case
the kernel would panic, thinking the fault was internal to it.
In particular, userland can create a broken segment in the ldt with
USER_LDT, update its %ss with setcontext and trigger the panic. I don't
think amd64 is affected since USER_LDT does not exist there, and the
changes on tf_ss seem correct - but I'm still adding T_STKFLT for safety.