[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 May 2021 13:56:16 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Rick Edgecombe <rick.p.edgecombe@...el.com>, dave.hansen@...el.com,
luto@...nel.org, linux-mm@...ck.org, x86@...nel.org,
akpm@...ux-foundation.org, linux-hardening@...r.kernel.org,
kernel-hardening@...ts.openwall.com, ira.weiny@...el.com,
rppt@...nel.org, dan.j.williams@...el.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/9] PKS write protected page tables
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?
There's also the HIGHPTE code we could abuse to kmap an alias while
we're at it.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
