From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "peterz@infradead.org" <peterz@infradead.org>,
"vbabka@suse.cz" <vbabka@suse.cz>
Cc: "kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"luto@kernel.org" <luto@kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rppt@kernel.org" <rppt@kernel.org>,
"linux-hardening@vger.kernel.org"
<linux-hardening@vger.kernel.org>,
"Weiny, Ira" <ira.weiny@intel.com>,
"Williams, Dan J" <dan.j.williams@intel.com>
Subject: Re: [PATCH RFC 0/9] PKS write protected page tables
Date: Wed, 5 May 2021 19:46:12 +0000 [thread overview]
Message-ID: <7279fce7e4921be698b3dd33069355f5e8993c8d.camel@intel.com> (raw)
In-Reply-To: <YJKH4HDuCGLArdmp@hirez.programming.kicks-ass.net>
On Wed, 2021-05-05 at 13:56 +0200, Peter Zijlstra wrote:
> On Wed, May 05, 2021 at 01:08:35PM +0200, Vlastimil Babka wrote:
> > On 5/5/21 2:30 AM, Rick Edgecombe wrote:
>
> > > Why use PKS for this?
> > > =====================
> > > PKS is an upcoming CPU feature that allows supervisor virtual
> > > memory
> > > permissions to be changed without flushing the TLB, like PKU does
> > > for user
> > > memory. Protecting page tables would normally be really expensive
> > > because you
> > > would have to do it with paging itself. PKS helps by providing a
> > > way to toggle
> > > the writability of the page tables with just a per-cpu MSR.
> >
> > I can see in patch 8/9 that you are flipping the MSR around
> > individual
> > operations on page table entries. In my patch I hooked making the
> > page table
> > writable to obtaining the page table lock (IIRC I had only the PTE
> > level fully
> > handled though). Wonder if that would be better tradeoff even for
> > your MSR approach?
>
Hmm, I see, that could reduce the sprinkling of the enable/disable
calls. It seems some(most?) of the kernel address space page table
modification don't take the page table locks though so those callers
would have to call something else to be able to write.
> There's also the HIGHPTE code we could abuse to kmap an alias while
> we're at it.
For a non-PKS debug feature?
It might fit pretty easily into CONFIG_DEBUG_PAGEALLOC on top of this
series. enable/disable_pgtable_write() could take a pointer that is
ignored in PKS mode, but triggers a cpa call in a
CONFIG_DEBUG_PAGETABLE_WRITE mode.
prev parent reply other threads:[~2021-05-05 19:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-05 0:30 [PATCH RFC 0/9] PKS write protected page tables Rick Edgecombe
2021-05-05 0:30 ` [PATCH RFC 1/9] list: Support getting most recent element in list_lru Rick Edgecombe
2021-05-05 0:30 ` [PATCH RFC 2/9] list: Support list head not in object for list_lru Rick Edgecombe
2021-05-05 0:30 ` [PATCH RFC 3/9] x86/mm/cpa: Add grouped page allocations Rick Edgecombe
2021-05-05 12:08 ` Mike Rapoport
2021-05-05 13:09 ` Peter Zijlstra
2021-05-05 18:45 ` Mike Rapoport
2021-05-05 21:57 ` Edgecombe, Rick P
2021-05-09 9:39 ` Mike Rapoport
2021-05-10 19:38 ` Edgecombe, Rick P
2021-05-05 0:30 ` [PATCH RFC 4/9] mm: Explicitly zero page table lock ptr Rick Edgecombe
2021-05-05 0:30 ` [PATCH RFC 5/9] x86, mm: Use cache of page tables Rick Edgecombe
2021-05-05 8:51 ` Peter Zijlstra
2021-05-05 12:09 ` Mike Rapoport
2021-05-05 13:19 ` Peter Zijlstra
2021-05-05 21:54 ` Edgecombe, Rick P
2021-05-06 17:59 ` Matthew Wilcox
2021-05-06 18:24 ` Shakeel Butt
2021-05-07 16:27 ` Edgecombe, Rick P
2021-05-05 0:30 ` [PATCH RFC 6/9] x86/mm/cpa: Add set_memory_pks() Rick Edgecombe
2021-05-05 0:30 ` [PATCH RFC 7/9] x86/mm/cpa: Add perm callbacks to grouped pages Rick Edgecombe
2021-05-05 0:30 ` [PATCH RFC 8/9] x86, mm: Protect page tables with PKS Rick Edgecombe
2021-05-05 0:30 ` [PATCH RFC 9/9] x86, cpa: PKS protect direct map page tables Rick Edgecombe
2021-05-05 2:03 ` [PATCH RFC 0/9] PKS write protected " Ira Weiny
2021-05-05 6:25 ` Kees Cook
2021-05-05 8:37 ` Peter Zijlstra
2021-05-05 18:38 ` Kees Cook
2021-05-05 19:51 ` Edgecombe, Rick P
2021-05-06 0:00 ` Ira Weiny
2021-05-05 11:08 ` Vlastimil Babka
2021-05-05 11:56 ` Peter Zijlstra
2021-05-05 19:46 ` Edgecombe, Rick P [this message]
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=7279fce7e4921be698b3dd33069355f5e8993c8d.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=ira.weiny@intel.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=rppt@kernel.org \
--cc=vbabka@suse.cz \
--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).