Messages in this thread | | | Date | Tue, 23 Jan 2018 09:01:01 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] x86/retpoline/entry: Disable the entire SYSCALL64 fast path with retpolines on |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, Jan 22, 2018 at 10:04 AM, Andy Lutomirski <luto@kernel.org> 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
| |