[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874kpxx4jf.fsf@nanos.tec.linutronix.de>
Date: Fri, 24 Jul 2020 00:14:28 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Andy Lutomirski <luto@...nel.org>
Cc: Fenghua Yu <fenghua.yu@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
Andy Lutomirski <luto@...nel.org>,
Weiny Ira <ira.weiny@...el.com>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <peterz@...radead.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
X86 ML <x86@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Vishal Verma <vishal.l.verma@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"open list\:DOCUMENTATION" <linux-doc@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-nvdimm <linux-nvdimm@...ts.01.org>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
"open list\:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH RFC V2 17/17] x86/entry: Preserve PKRS MSR across exceptions
Andy Lutomirski <luto@...nel.org> writes:
>> On Jul 23, 2020, at 1:22 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
>> Andy Lutomirski <luto@...capital.net> writes:
>>> My suggestion is to enlarge pt_regs. The save and restore logic can
>>> probably be in C, but pt_regs is the logical place to put a register
>>> that is saved and restored across all entries.
>>
>> Kinda, but that still sucks because schedule from #PF will get it wrong
>> unless you do extra nasties.
>
> This seems like we’re reinventing the wheel. PKRS is not
> fundamentally different from, say, RSP. If we want to save it across
> exceptions, we save it on entry and context-switch-out and restore it
> on exit and context-switch-in.
It's fundamentally different from RSP because it has state (refcount)
attached, which RSP clearly has not. If you get rid of the state then
yes.
>>> Whoever does this work will have the delightful job of figuring out
>>> whether BPF thinks that the layout of pt_regs is ABI and, if so,
>>> fixing the resulting mess.
>>>
>>> The fact the new fields will go at the beginning of pt_regs will make
>>> this an entertaining prospect.
>>
>> Good luck with all of that.
>
> We can always cheat like this:
>
> struct real_pt_regs {
> unsigned long pkrs;
> struct pt_regs regs;
> };
>
> and pass a pointer to regs around. What BPF doesn't know about can't hurt it.
Yes, but that's the easy part of the problem :)
Thanks,
tglx
Powered by blists - more mailing lists