[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <71f0e3d8-6dfa-742d-eaa7-330b59611e2f@intel.com>
Date: Thu, 23 Jul 2020 10:30:31 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Andy Lutomirski <luto@...capital.net>,
Fenghua Yu <fenghua.yu@...el.com>
Cc: Andy Lutomirski <luto@...nel.org>, Weiny Ira <ira.weiny@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
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
On 7/23/20 10:08 AM, Andy Lutomirski wrote:
> Suppose some kernel code (a syscall or kernel thread) changes PKRS
> then takes a page fault. The page fault handler needs a fresh PKRS.
> Then the page fault handler (say a VMA’s .fault handler) changes
> PKRS. The we get an interrupt. The interrupt *also* needs a fresh
> PKRS and the page fault value needs to be saved somewhere.
>
> So we have more than one saved value per thread, and thread_struct
> isn’t going to solve this problem.
Taking a step back... This is all true only if we decide that we want
protection keys to provide protection during exceptions and interrupts.
Right now, the code supports nesting:
kmap(foo);
kmap(bar);
kunmap(bar);
kunmap(foo);
with a reference count. So, the nested kmap() will see the count
elevated and do nothing.
I'm generally OK with this getting merged without extending PKS
protection to interrupts and exceptions. Ira and Fenghua should
certainly give it a go, but I'd like to see it as an add-on feature and
we can judge the benefits versus complexity separately.
Ira was looking at adding it because it _looked_ simple. Andy has me
really scared about it now. :)
Powered by blists - more mailing lists