Messages in this thread | | | Date | Tue, 22 Apr 2014 10:59:21 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE* |
| |
On 04/22/2014 10:46 AM, Andrew Lutomirski wrote: >> >> That is the whole impact of the IRET path. >> >> If using IST for #GP won't cause trouble (ISTs don't nest, so we need to >> make sure there is absolutely no way we could end up nested) then the >> rest of the fixup code can go away and we kill the common path >> exception-handling overhead; the only new overhead is the IST >> indirection for #GP, which isn't a performance-critical fault (good >> thing, because untangling #GP faults is a major effort.) > > I'd be a bit nervous about read_msr_safe and friends. Also, what > happens if userspace triggers a #GP and the signal stack setup causes > a page fault? >
Yes, #GPs inside the kernel could be a real problem. MSRs generally don't trigger #SS. The second scenario shouldn't be a problem, the #PF will be delivered on the currently active stack.
On the other hand, doing the espfix fixup only for #GP might be an alternative, as long as we can convince ourselves that it really is the only fault that could possibly be delivered on the espfix path.
-hpa
| |