Messages in this thread | | | Subject | Re: [PATCH] sched/x86: Save [ER]FLAGS on context switch | From | Julien Thierry <> | Date | Tue, 19 Feb 2019 09:07:00 +0000 |
| |
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@linux-foundation.org> wrote: >>> >>>> On Mon, Feb 18, 2019 at 2:31 PM H. Peter Anvin <hpa@zytor.com> 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...
Thanks,
-- Julien Thierry
| |