From: Ira Weiny <ira.weiny@intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"keescook@chromium.org" <keescook@chromium.org>
Cc: "kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
"luto@kernel.org" <luto@kernel.org>,
"Hansen, Dave" <dave.hansen@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"rppt@kernel.org" <rppt@kernel.org>,
"vbabka@suse.cz" <vbabka@suse.cz>,
"linux-hardening@vger.kernel.org"
<linux-hardening@vger.kernel.org>,
"shakeelb@google.com" <shakeelb@google.com>,
"Weiny, Ira" <ira.weiny@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"ardb@google.com" <ardb@google.com>
Subject: Re: [RFC PATCH v2 00/19] PKS write protected page tables
Date: Thu, 14 Mar 2024 11:25:50 -0700 [thread overview]
Message-ID: <65f3412e598c8_13f3a29410@iweiny-mobl.notmuch> (raw)
In-Reply-To: <3b3c941f1fb69d67706457a30cecc96bfde57353.camel@intel.com>
Edgecombe, Rick P wrote:
> 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).
This was the main reason it got dropped.
> 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.
I can help with reviews as well,
Ira
>
>
> [0] https://lwn.net/Articles/931406/
next prev parent reply other threads:[~2024-03-14 18:26 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-30 23:59 [RFC PATCH v2 00/19] PKS write protected page tables Rick Edgecombe
2021-08-30 23:59 ` [RFC PATCH v2 01/19] list: Support getting most recent element in list_lru Rick Edgecombe
2021-08-30 23:59 ` [RFC PATCH v2 02/19] list: Support list head not in object for list_lru Rick Edgecombe
2021-08-30 23:59 ` [RFC PATCH v2 03/19] x86/mm/cpa: Add grouped page allocations Rick Edgecombe
2021-08-30 23:59 ` [RFC PATCH v2 04/19] mm: Explicitly zero page table lock ptr Rick Edgecombe
2021-08-30 23:59 ` [RFC PATCH v2 05/19] x86, mm: Use cache of page tables Rick Edgecombe
2021-08-31 8:40 ` Mike Rapoport
2021-08-31 19:09 ` Edgecombe, Rick P
2021-08-30 23:59 ` [RFC PATCH v2 06/19] x86/mm/cpa: Add perm callbacks to grouped pages Rick Edgecombe
2021-08-30 23:59 ` [RFC PATCH v2 07/19] x86/cpufeatures: Add feature for pks tables Rick Edgecombe
2021-08-30 23:59 ` [RFC PATCH v2 08/19] x86/mm/cpa: Add get_grouped_page_atomic() Rick Edgecombe
2021-08-30 23:59 ` [RFC PATCH v2 09/19] x86/mm: Support GFP_ATOMIC in alloc_table_node() Rick Edgecombe
2021-08-31 8:32 ` Mike Rapoport
2021-08-30 23:59 ` [RFC PATCH v2 10/19] x86/mm: Use alloc_table() for fill_pte(), etc Rick Edgecombe
2021-08-31 8:47 ` Mike Rapoport
2021-08-31 18:48 ` Edgecombe, Rick P
2021-08-30 23:59 ` [RFC PATCH v2 11/19] mm/sparsemem: Use alloc_table() for table allocations Rick Edgecombe
2021-08-31 8:55 ` Mike Rapoport
2021-08-31 18:25 ` Edgecombe, Rick P
2021-09-01 7:22 ` Mike Rapoport
2021-09-02 13:56 ` Vlastimil Babka
2021-08-30 23:59 ` [RFC PATCH v2 12/19] x86/mm: Use free_table in unmap path Rick Edgecombe
2021-08-30 23:59 ` [RFC PATCH v2 13/19] mm/debug_vm_page_table: Use setters instead of WRITE_ONCE Rick Edgecombe
2021-08-30 23:59 ` [RFC PATCH v2 14/19] x86/efi: Toggle table protections when copying Rick Edgecombe
2021-08-30 23:59 ` [RFC PATCH v2 15/19] x86/mm/cpa: Add set_memory_pks() Rick Edgecombe
2021-08-30 23:59 ` [RFC PATCH v2 16/19] x86/mm: Protect page tables with PKS Rick Edgecombe
2021-08-31 8:56 ` Mike Rapoport
2021-08-31 17:55 ` Edgecombe, Rick P
2021-08-30 23:59 ` [RFC PATCH v2 17/19] x86/mm/cpa: PKS protect direct map page tables Rick Edgecombe
2021-08-31 10:14 ` Mike Rapoport
2021-08-31 17:58 ` Edgecombe, Rick P
2021-08-30 23:59 ` [RFC PATCH v2 18/19] x86/mm: Add PKS table soft mode Rick Edgecombe
2021-08-31 3:49 ` Randy Dunlap
2021-08-31 17:55 ` Edgecombe, Rick P
2021-08-30 23:59 ` [RFC PATCH v2 19/19] x86/mm: Add PKS table debug checking Rick Edgecombe
2024-03-14 16:27 ` [RFC PATCH v2 00/19] PKS write protected page tables Kees Cook
2024-03-14 17:10 ` Edgecombe, Rick P
2024-03-14 18:25 ` Ira Weiny [this message]
2024-03-14 21:02 ` Boris Lukashev
2024-03-16 3:14 ` Boris Lukashev
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=65f3412e598c8_13f3a29410@iweiny-mobl.notmuch \
--to=ira.weiny@intel.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@google.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=keescook@chromium.org \
--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=rick.p.edgecombe@intel.com \
--cc=rppt@kernel.org \
--cc=shakeelb@google.com \
--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).