Messages in this thread | | | Date | Mon, 28 Apr 2014 16:05:41 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE* |
| |
On 04/23/2014 09:53 PM, Andrew Lutomirski wrote: > > This particular vector hurts: you can safely keep trying until it works. > > This just gave me an evil idea: what if we make the whole espfix area > read-only? This has some weird effects. To switch to the espfix > stack, you have to write to an alias. That's a little strange but > harmless and barely complicates the implementation. If the iret > faults, though, I think the result will be a #DF. This may actually > be a good thing: if the #DF handler detects that the cause was a bad > espfix iret, it could just return directly to bad_iret or send the > signal itself the same way that do_stack_segment does. This could > even be written in C :) > > Peter, is this idea completely nuts? The only exceptions that can > happen there are NMI, MCE, #DB, #SS, and #GP. The first four use IST, > so they won't double-fault. >
So I tried writing this bit up, but it fails in some rather spectacular ways. Furthermore, I have been unable to debug it under Qemu, because breakpoints don't work right (common Qemu problem, sadly.)
The kernel code is at:
https://git.kernel.org/cgit/linux/kernel/git/hpa/espfix64.git/
There are two tests:
git://git.zytor.com/users/hpa/test16/test16.git, build it, and run ./run16 test/hello.elf http://www.zytor.com/~hpa/ldttest.c
The former will exercise the irq_return_ldt path, but not the fault path; the latter will exercise the fault path, but doesn't actually use a 16-bit segment.
Under the 3.14 stock kernel, the former should die with SIGBUS and the latter should pass.
-hpa
| |