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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/