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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A370C54E60 for ; Thu, 14 Mar 2024 21:03:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20C4B800E5; Thu, 14 Mar 2024 17:03:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BD6A800B4; Thu, 14 Mar 2024 17:03:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05E11800E5; Thu, 14 Mar 2024 17:03:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E4507800B4 for ; Thu, 14 Mar 2024 17:03:13 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B3C6FC02D0 for ; Thu, 14 Mar 2024 21:03:13 +0000 (UTC) X-FDA: 81896869866.28.23269A6 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf12.hostedemail.com (Postfix) with ESMTP id D79A04001D for ; Thu, 14 Mar 2024 21:03:10 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=sempervictus-com.20230601.gappssmtp.com header.s=20230601 header.b=XILNPDU8; dmarc=none; spf=pass (imf12.hostedemail.com: domain of blukashev@sempervictus.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=blukashev@sempervictus.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710450191; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=AzuHIDVnpodvf8Yk4kbRsSjN+JkysTBQ+d66KpBJz9I=; b=lvUIwR+PQn1Vg4L4ge1P/2PPwr2ZKv7oFP+KQWtZfQ7+z+T69ROW+y6jWgJQclbrmDE5Q3 QI4THcklT6p5fOLATs5N93SUo2LlH/WGUrlfil4ut6fpaaR1Z9IQNzjdLS1FiKZzjK0qlF f17S1UTdNVGRxbFmXOjnGO1GRQTg64I= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=sempervictus-com.20230601.gappssmtp.com header.s=20230601 header.b=XILNPDU8; dmarc=none; spf=pass (imf12.hostedemail.com: domain of blukashev@sempervictus.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=blukashev@sempervictus.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710450191; a=rsa-sha256; cv=none; b=N/v4km5SYtNogSY1V6hMYYZR8zFL7C3gqZ+ArBitHtFbLwrD3mrPDxTQFYoNrrQVsKWbFr Y++mNfdnPQiBu0j3WLeVZVySrtmBF5oHffhUn9AqIoklRDrHv1NeWBuJY+6pE4XFdWZB8A piNNdhB36B4SVFd4ZaEuUyRY5o8vFZ4= Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-dcc84ae94c1so1316610276.1 for ; Thu, 14 Mar 2024 14:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sempervictus-com.20230601.gappssmtp.com; s=20230601; t=1710450190; x=1711054990; darn=kvack.org; 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=XILNPDU8ZnHJHf64RuuKdp5xJKpr5ggvSk9Eh2YS8IXJAJ1INRzcnLcUQIwTtStBcj QVDYodZML2Ptm10vVJyiKJKDaBD4N/OqDVXABrjclyF3mNH+BvH9xf6bzO31D5NttxT9 3R/IG/QadV9/d0IAGDXaO5mk3R/Uky7UHXAH2V61mSaXZMPjfwKsm9v+6hKjHbdN0p8q +3BsG39PGi2zQRM9giqwkNL1ZJycyk3MKCP9xrvUjX8MpGgtroHAMADK1cwfWSzaoRkv omzahIJmC0dc8MClhWfen8V0cwALhDJnYVOhj6uQZZoaqS2sQoqLUCap188etvg0m4kH /NLQ== 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=SG6eT/XNwoKYH1OhVM2MNyCnJKu3KoObMfMmaMROPO8GqZLHfzg8wumsCMOFZAqQkH IfUFDe63euDq0KWrAmfiS3yFNwdUYXQSPPgkPu+pwSwhviAacLCxSwMOzZAdXP0idthz tZbyx0zISq0GL7yGluWBhROri9bgTLcXoIb1wMLybvZtO72MBm+2r1w0dJ7dhtfOOZE+ Q8+tDJD45EOc9JczzcS+o2p8OVyqoOvqmmmKGQlqMYup092Wa/nbHG8PPnyrmvAuiAUB 1h2dUHVXL9dwKk1ZeIHWYE8pckYFll/psrMbkGnF9vZF5FwCtYof9cDiLWuw6ZM701j6 dftg== X-Forwarded-Encrypted: i=1; AJvYcCUdF4Wqfbl89nxAa02dlYFbrnmU5pwS/IvZ6Hy7FiNqzTrZmRskg4kZo/YIv5nleIayQ9a8c9YvjFMZB5YcalWSM94= X-Gm-Message-State: AOJu0YwJfhXlIWulQ0Yuktb2/96q892jelWFGhAR1batv0GUZuIspDuQ U0WspcLXkdT9fdkXGgAXSQyJJ4pyoYjEoqjSpnbX6omwNjE+1ss5sgX4267b6pU9NqGt6mmxbNj vdS3lh7JPov1hQBIahvVq4GmIIeC7FkfV6GEc3Q== 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" X-Rspamd-Queue-Id: D79A04001D X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 53ykm1ecxakx85z1sornm5c6c1h3aswm X-HE-Tag: 1710450190-405927 X-HE-Meta: U2FsdGVkX18LUO25fArHQN4YUrA4aByXnv+sjxMBVxHQc6MeAIxE9L2feYwW2/gHBn7beH5Ms6LASBPTbldcRMQpa2Pb7anKunc7orGNNS8MiHua79l64RzE+2ZYHEU5obd0MCIzq2oKy+MrkojaIY+cGv+H1V1xrabap7dl4wS6vX+SjiDkIz1xLOFiJ/jw+SZFEkpml9zyhUH5zWLC1eHfO3C52RHqdiqsPnkG0ewz2Gm3+UiLM7AKornw6K5qVzGNlHVw4m9za4eTcgCYMsOtZvOHxytCote4ur4PFidTEs0rlehQ+eWktVk1qKMvTBfThl4ZcStUB4o7u9PfLFpJ6nPCwpZ+8UuJpz+6BSxPqKTHN+H2IzhhRZdVJ6IX47Qv0+dhZgwbdtWlFX5xjo3hs7lfNuajsnrAmSElEJnM58uHPE0bv+iqaF4zVnqsyGJvJvjqUG8xuruLPpaplnNMcgzWfzuvLMD1APUQu4m5QBPsOAmSX7LbvJrWYc+VZV1xKZMwVbxjYMWpp84XKHTMQqugRJlQdJPw8uZbm+4iV//GM/gwHUF+relHHB0tKvi68yF+V2BbhyZGbj1Z3tp4Ohv2QIqi6ggWxF4O3Ud3dTP0ZF3iWDKV/sBt8p6hY9BnIJv+YQzLKQk9OgTiDlXgi1Ght+gRs97bUjUYylHRfWOHAELwQaveOKH60J+IcDYVGL2hPPX3q1Ep6LlllCFetI4c1X/HBAQW76zuo4bmha0tkZe9p6m1xH8dJGnTzg4KQmcHRz9j6G84hXuNEcbTwGnlJt3N1OEqESfBftpxW9EYU/4ErTFzLONBkEHV6kyywE0/WO9hVk73z+Y+qPFQEwwNo8bqRSurGKlU9GpDzsOdPWN1vpmSYHN6fQ8ZRHW3s1QejA1iY5g0zrZCvQkFl2BsVRB4p4GZOiq+ALdeaA87mvISMpFFgmzC/SrMiAUHHFJm7RVOjDUJqyX LQwTC0Vm B3pJ/FH+Laz85DWIattYVZGZcb7/biZRG8GLxcZIcBqqYiIA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001715, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --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--