On 04/02/2015 01:14 PM, Brian Gerst wrote: >>>> So I merged this as it's an obvious bugfix, but in hindsight I'm >>>> really uneasy about the whole opportunistic SYSRET concept: it appears >>>> that the chance that %rcx matches return-%rip is astronomical - this >>>> is why this bug wasn't noticed live so far. >>>> >>>> So should we really be doing this? >>> >>> Andy does this not for the off-chance that userspace's RCX is equal >>> to return address and R11 == RFLAGS. The chances of that are >>> astronomically small. >>> >>> This code path triggers when ptrace/audit/seccomp is active. Instead >>> of torturing ourselves trying to not divert into IRET return, now >>> code is steered that way. But then immediately before actual IRET, >>> we check again: "do we really need IRET?" IOW "did ptrace really >>> touch pt_regs->ss? ->flags? ->rip? ->rcx?" which in vast majority of >>> cases will not be true. >> >> I keep forgetting about that, my test systems have the audit muck >> turned off ;-) >> >> Fair enough - and it's sensible to share the IRET path between >> interrupts and complex-return system calls, even though the check >> is unnecessary overhead for the pure interrupt return path... > > > Maybe we could reintroduce TIF_IRET for this purpose instead of > (ab)using TIF_NOTIFY_RESUME. Then we would only do the opportunistic > check for those cases (ptrace, audit, exec, sigreturn, etc.), and skip > it for interrupts.
The very first check in the existing code, pt_regs->cx == pt_regs->ip, will fail for interrupt returns. You hardly can save anything by placing a (ti->flags & TIF_TRY_SYSRET) check in front of it, it's almost as expensive. -- 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/
