Re: [PATCH] x86/retpoline/entry: Disable the entire SYSCALL64 fast path with retpolines on

From: Ingo Molnar
Date: Tue Jan 23 2018 - 03:01:12 EST



* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Mon, Jan 22, 2018 at 10:04 AM, Andy Lutomirski <luto@xxxxxxxxxx> wrote:
> > The existing retpoline code carefully and awkwardly retpolinifies
> > the SYSCALL64 slow path. This stops the fast path from being
> > particularly fast, and it's IMO rather messy.
>
> I'm not convinced your patch isn't messier still.. It's certainly
> subtle. I had to look at that ptregs stub generator thing twice.
>
> Honestly, I'd rather get rid of the fast-path entirely. Compared to
> all the PTI mess, it's not even noticeable.
>
> And if we ever get CPU's that have this all fixed, we can re-visit
> introducing the fastpath. But this is all very messy and it doesn't
> seem worth it right now.
>
> If we get rid of the fastpath, we can lay out the slow path slightly
> better, and get rid of some of those jump-overs. And we'd get rid of
> the ptregs hooks entirely.
>
> So we can try to make the "slow" path better while at it, but I really
> don't think it matters much now in the post-PTI era. Sadly.

Note that there's another advantage to your proposal: should other vulnerabilities
arise in the future, requiring changes in the syscall entry path, we'd be more
flexible to address them in the C space than in the assembly space.

In hindsight a _LOT_ of the PTI complexity and fragility centered around
interacting with x86 kernel entry assembly code - which entry code fortunately got
much simpler (and easier to review) in the past 1-2 years due to the thorough
cleanups and the conversion of most of it to C. But it was still painful.

So I'm fully in favor of that.

Thanks,

Ingo