Re: [PATCH] sched/x86: Save [ER]FLAGS on context switch
From: Julien Thierry
Date: Tue Feb 19 2019 - 04:07:25 EST
On 19/02/2019 02:46, H. Peter Anvin wrote:
> On 2/18/19 6:20 PM, Andy Lutomirski wrote:
>>> On Feb 18, 2019, at 4:24 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>>>> On Mon, Feb 18, 2019 at 2:31 PM H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>>>> The question is what "fix it" means. I'm really concerned about AC escapes,
>>>> and everyone else should be, too.
>>> I do think that it might be the right thing to do to add some kind of
>>> WARN_ON_ONCE() for AC being set in various can-reschedule situations.
>>> We'd just have to abstract it sanely. I'm sure arm64 has the exact
>>> same issue with PAN - maybe it saves properly, but the same "we
>>> wouldn't want to go through the scheduler with PAN clear".
>>> On x86, we might as well check DF at the same time as AC.
>> hpa is right, though â calling into tracing code with AC set is not really so good. And calling schedule() (via preempt_enable() or whatever) is also bad because it runs all the scheduler code with AC on. Admittedly, the scheduler is not *that* interesting of an attack surface.
> Not just that, but the other question is just how much code we are running
> with AC open. It really should only be done in some very small regions.
Yes, but we don't really have a way to enforce that, as far as I'm aware.
The user_access_begin/end() is generic API, meaning any arch is free to
implement it. If they don't have the same hardware behaviour as
x86/arm64, it might be that their interrupt/exception entry code will
run with user_access open until they reach the entry code that closes it
(and entry code could potentially be a more interesting attack surface
than the scheduler). This could be the case of software emulated PAN on
arm/arm64 (although currently arm, non-64bit, doesn't have
user_access_begin/end() at the time).
So the whole "very small region" restriction sounds a bit
loose/arbitrary to me...