From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by smtp.lore.kernel.org (Postfix) with SMTP id 81BBFC54E60 for ; Thu, 14 Mar 2024 21:03:28 +0000 (UTC) Received: (qmail 23613 invoked by uid 550); 14 Mar 2024 20:59:04 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 23574 invoked from network); 14 Mar 2024 20:59:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sempervictus-com.20230601.gappssmtp.com; s=20230601; t=1710450190; x=1711054990; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AzuHIDVnpodvf8Yk4kbRsSjN+JkysTBQ+d66KpBJz9I=; b=HmhogfSOD3nUcavJezU1pOgyD3WuS42O7abuf/4y3IdOGsErHLnUQr+aEli38KlXwj TfqJxl/mh8ZxGvlXZZd4bIHvn1y9zsoFZNhDbCFq69QwU8tdAjZeyozssTnpcbBV9vIw morx7PGqDzsJwMP1zZjiWp3oeFO1n4ee959nf5sUcXkJV+xeBOup67SY/wdY3g3NbmMR 7+w0dCf5SdFdydxtB0GT7Hrp86BMd8vczbxu4Ob0E9gv3z1CNq4c6a8VQkreIXtQejxe EEdYWNKY1+7+KQmQminKEBDorvA8ILUTGk7N61EX7btzUlh5bZ7EXvL31aIiEDF0w3Yd CTrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710450190; x=1711054990; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AzuHIDVnpodvf8Yk4kbRsSjN+JkysTBQ+d66KpBJz9I=; b=BMTYxKG+Bb/+VHis5q2apubM6CvOD8AjHE/odYdRFM3huZw04tx7v5OQ/LT2vVMir5 SdtKg/ov6tXouGKjzcyAk9sGhlTdCFu3Sg4pmFSf+DwgXmpt9bQ3aFC2zzM6cFBrjB9C DtsgfaiUqmG5JsfRgfUNjbvxtfLKfJKbuWHilXqv9yWmr6R+Ltg6OBxZXgUwZF3lOr9l 0xmqdLnNCcApCky77SrAz3pbuEZ9PLj7HktnAIRGXCZThXJChd+WilubfnIyS+3z7vJt Bck2WVQ3v496IN3vQjtuD+yExOjbbgs4ot7CMocAjU/huI/atV9X/oXfsRSKiBFdDc06 N+mw== X-Forwarded-Encrypted: i=1; AJvYcCUSPaqHj1foCXMXH4RDLeyjxEABR2bMKuXovzGfrm3E2Inl3Ql5+2whPAY8vcysbFEjTkArqN2x1B5UIcCXAVfsH6Snr4VES0CegQq3agZPvkHLmw== X-Gm-Message-State: AOJu0YzXW7b4fgJA1bw3hPzDhB9yleirhoMVI3nQ3SXZbFV+OzGV/DBm Az7r7wzMCDmYeVn8Bu+TFcgOvdHEz6RiUkOYzvPGqLCfa7MtoEytuw3Yg6YY3Y7SJXZas3DYwRt m3do43yaz8Utbvj38kUflIaJh6xg12w0zIgRlzJdt+US2RTSuYtM= X-Google-Smtp-Source: AGHT+IGMBFRkxWjovdYSwAgw4fKNsLNeovNhukMUMNExBSIAMrIyRb0al87GLoaAFe3JL0D53s8FU083uXXQJmIWDdM= X-Received: by 2002:a25:aaec:0:b0:dc2:40d8:ac5e with SMTP id t99-20020a25aaec000000b00dc240d8ac5emr3170960ybi.1.1710450189781; Thu, 14 Mar 2024 14:03:09 -0700 (PDT) MIME-Version: 1.0 References: <20210830235927.6443-1-rick.p.edgecombe@intel.com> <202403140927.5A5F290@keescook> <3b3c941f1fb69d67706457a30cecc96bfde57353.camel@intel.com> <65f3412e598c8_13f3a29410@iweiny-mobl.notmuch> In-Reply-To: <65f3412e598c8_13f3a29410@iweiny-mobl.notmuch> From: Boris Lukashev Date: Thu, 14 Mar 2024 17:02:58 -0400 Message-ID: Subject: Re: [RFC PATCH v2 00/19] PKS write protected page tables To: Ira Weiny Cc: "Edgecombe, Rick P" , "keescook@chromium.org" , "kernel-hardening@lists.openwall.com" , "luto@kernel.org" , "Hansen, Dave" , "x86@kernel.org" , "akpm@linux-foundation.org" , "peterz@infradead.org" , "linux-mm@kvack.org" , "rppt@kernel.org" , "vbabka@suse.cz" , "linux-hardening@vger.kernel.org" , "shakeelb@google.com" , "linux-kernel@vger.kernel.org" , "Williams, Dan J" , "ardb@google.com" Content-Type: multipart/alternative; boundary="000000000000f7ef5e0613a537e6" --000000000000f7ef5e0613a537e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IIRC shoot-downs are one of the reasons for using per-cpu PGDs which would be a hard sell to some people. https://forum.osdev.org/viewtopic.php?f=3D15&t=3D29661 -Boris On Thu, Mar 14, 2024 at 2:26=E2=80=AFPM Ira Weiny wro= te: > 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/ > > > --=20 Boris Lukashev Systems Architect Semper Victus --000000000000f7ef5e0613a537e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IIRC shoot-downs are one of the reasons for using per= -cpu PGDs which would be a hard sell to some people.

-Bo= ris

On Thu, Mar 14, 2024 at 2:26=E2=80=AFPM Ira Weiny <ira.weiny@intel.com> wrote:
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 conc= ept.
> > > I'm sharing to
> > > show the progress to interested people. I'd also appreci= ate 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 merge= d?
>
> 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<= br> > 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<= br> > 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/




--
Boris Lukashev
Systems A= rchitect
Semp= er Victus
--000000000000f7ef5e0613a537e6--