From: Ira Weiny <ira.weiny@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Andy Lutomirski <luto@kernel.org>,
Fenghua Yu <fenghua.yu@intel.com>,
x86@kernel.org, Dave Hansen <dave.hansen@linux.intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-kselftest@vger.kernel.org
Subject: Re: [RFC PATCH 04/15] x86/pks: Preserve the PKRS MSR on context switch
Date: Tue, 14 Jul 2020 11:53:22 -0700 [thread overview]
Message-ID: <20200714185322.GB3008823@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <20200714082701.GO10769@hirez.programming.kicks-ass.net>
On Tue, Jul 14, 2020 at 10:27:01AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 12:02:09AM -0700, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > The PKRS MSR is defined as a per-core register. This isolates memory
> > access by CPU. Unfortunately, the MSR is not preserved by XSAVE.
> > Therefore, We must preserve the protections for individual tasks even if
> > they are context switched out and placed on another cpu later.
>
> This is a contradiction and utter trainwreck.
I don't understand where there is a contradiction? Perhaps I should have said
the MSR is not XSAVE managed vs 'preserved'?
> We're not going to do more
> per-core MSRs and pretend they make sense per-task.
I don't understand how this does not make sense. The PKRS register is
controlling the task's access to kernel memory and is designed to be restricted
to that task. Put another way, this is similar to CR3 which ultimately
controls tasks memory access. Per-process mm is inherent to memory access
control and is per-task. So how is this any different? Many MSRs are like
this.
I suppose an alternative might be to disallow a context switch while the PKRS
value is not the default but I don't see this being very desirable at all.
Ira
next prev parent reply other threads:[~2020-07-14 18:53 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 7:02 [RFC PATCH 00/15] PKS: Add Protection Keys Supervisor (PKS) support ira.weiny
2020-07-14 7:02 ` [RFC PATCH 01/15] x86/pkeys: Create pkeys_internal.h ira.weiny
2020-07-14 7:02 ` [RFC PATCH 02/15] x86/fpu: Refactor arch_set_user_pkey_access() for PKS support ira.weiny
2020-07-14 7:02 ` [RFC PATCH 03/15] x86/pks: Enable Protection Keys Supervisor (PKS) ira.weiny
2020-07-14 7:02 ` [RFC PATCH 04/15] x86/pks: Preserve the PKRS MSR on context switch ira.weiny
2020-07-14 8:27 ` Peter Zijlstra
2020-07-14 18:53 ` Ira Weiny [this message]
2020-07-14 18:56 ` Dave Hansen
2020-07-14 19:05 ` Peter Zijlstra
2020-07-14 19:09 ` Ira Weiny
2020-07-14 7:02 ` [RFC PATCH 05/15] x86/pks: Add PKS kernel API ira.weiny
2020-07-14 7:02 ` [RFC PATCH 06/15] x86/pks: Add a debugfs file for allocated PKS keys ira.weiny
2020-07-14 7:02 ` [RFC PATCH 07/15] Documentation/pkeys: Update documentation for kernel pkeys ira.weiny
2020-07-14 7:02 ` [RFC PATCH 08/15] x86/pks: Add PKS Test code ira.weiny
2020-07-14 7:02 ` [RFC PATCH 09/15] fs/dax: Remove unused size parameter ira.weiny
2020-07-14 7:02 ` [RFC PATCH 10/15] drivers/dax: Expand lock scope to cover the use of addresses ira.weiny
2020-07-14 7:02 ` [RFC PATCH 11/15] memremap: Add zone device access protection ira.weiny
2020-07-14 8:40 ` Peter Zijlstra
2020-07-14 19:10 ` Ira Weiny
2020-07-14 19:40 ` Peter Zijlstra
2020-07-14 7:02 ` [RFC PATCH 12/15] kmap: Add stray write protection for device pages ira.weiny
2020-07-14 8:44 ` Peter Zijlstra
2020-07-14 19:06 ` Ira Weiny
2020-07-14 19:29 ` Peter Zijlstra
2020-07-14 19:42 ` Dave Hansen
2020-07-14 19:49 ` Peter Zijlstra
2020-07-14 20:00 ` Ira Weiny
2020-07-14 7:02 ` [RFC PATCH 13/15] dax: Stray write protection for dax_direct_access() ira.weiny
2020-07-14 7:02 ` [RFC PATCH 14/15] nvdimm/pmem: Stray write protection for pmem->virt_addr ira.weiny
2020-07-14 7:02 ` [RFC PATCH 15/15] [dax|pmem]: Enable stray write protection ira.weiny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200714185322.GB3008823@iweiny-DESK2.sc.intel.com \
--to=ira.weiny@intel.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=vishal.l.verma@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).