linux-hardening - Re: [RFC PATCH v2 00/19] PKS write protected page tables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3b3c941f1fb69d67706457a30cecc96bfde57353.camel@intel.com>
Date: Thu, 14 Mar 2024 17:10:42 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "keescook@...omium.org" <keescook@...omium.org>
CC: "kernel-hardening@...ts.openwall.com"
	<kernel-hardening@...ts.openwall.com>, "luto@...nel.org" <luto@...nel.org>,
	"Hansen, Dave" <dave.hansen@...el.com>, "x86@...nel.org" <x86@...nel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"peterz@...radead.org" <peterz@...radead.org>, "linux-mm@...ck.org"
	<linux-mm@...ck.org>, "rppt@...nel.org" <rppt@...nel.org>, "vbabka@...e.cz"
	<vbabka@...e.cz>, "linux-hardening@...r.kernel.org"
	<linux-hardening@...r.kernel.org>, "shakeelb@...gle.com"
	<shakeelb@...gle.com>, "Weiny, Ira" <ira.weiny@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Williams, Dan
 J" <dan.j.williams@...el.com>, "ardb@...gle.com" <ardb@...gle.com>
Subject: Re: [RFC PATCH v2 00/19] PKS write protected page tables

On Thu, 2024-03-14 at 09:27 -0700, Kees Cook wrote:
> On Mon, Aug 30, 2021 at 04:59:08PM -0700, Rick Edgecombe wrote:
> > This is a second RFC for the PKS write protected tables concept.
> > I'm sharing to
> > show the progress to interested people. I'd also appreciate any
> > comments,
> > especially on the direct map page table protection solution (patch
> > 17).
> 
> *thread necromancy*
> 
> Hi,
> 
> Where does this series stand? I don't think it ever got merged?

There are sort of three components to this:
1. Basic PKS support. It was dropped after the main use case was
rejected (pmem stray write protection).
2. Solution for applying direct map permissions efficiently. This
includes avoiding excessive kernel shootdowns, as well as avoiding
direct map fragmentation. rppt continued to look at the fragmentation
part of the problem and ended up arguing that it actually isn't an
issue [0]. Regardless, the shootdown problem remains for usages like
PKS tables that allocate so frequently. There is an attempt to address
both in this series. But given the above, there may be lots of debate
and opinions.
3. The actual protection of the PKS tables (most of this series). It
got paused when I started to work on CET. In the meantime 1 was
dropped, and 2 is still open(?). So there is more to work through now,
then when it was dropped.

If anyone wants to pick it up, it is fine by me. I can help with
reviews.

[0] https://lwn.net/Articles/931406/