On Thu, May 1, 2014 at 2:58 PM, H. Peter Anvin <h...@zytor.com> wrote: > On 05/01/2014 02:15 PM, Andi Kleen wrote: >>> If usergs == kernelgs, then ebx will always be 1 and we'll never end >>> up in paranoid_userspace. >> >> You may miss a reschedule in this obscure case. It shouldn't really >> happen because loading a kernel pointer is not useful for user space. >> >> Doesn't seem like a real issue to me. >> >> We only happen need to handle it to avoid crashing. >> > > No, it would be a rootable security hole, not just a crash. > >>> Alternatively, what if the paranoid entry checked whether we're coming >>> from userspace at the very beginning and, if so, just jumped to the >>> non-paranoid entry? >> >> That would work, but I doubt it would be worth it. > > If that would solve the problem it is simple enough, but the tricky part > is when we end up in a "crack" where we are in kernel mode with the user GS. > > I haven't looked through the flows (I'm at LCE so I have limited screen > bandwidth) to see how that would be handled in this case, but in the > general paranoid case it comes down to the fact that in this particular > subcase we don't necessarily know exactly how many SWAPGS are between us > and userspace after we IRET.
The current code looks like it will never try to reschedule on paranoid exit unless it came from user *CS*, in which case there shouldn't be any weird gs issues. Given that the current code won't reschedule even on a paranoid entry that hits during interruptable kernel code, I find it unlikely that this code is important. You probably know more about its history and significance than I do. What happens when ftrace or perf tries to wake a task from a debug interrupt or NMI? --Andy -- 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/