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.
