From: Peter Zijlstra <peterz@infradead.org>
To: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
aruna.ramakrishna@oracle.com, broonie@kernel.org,
catalin.marinas@arm.com, dave.hansen@linux.intel.com,
jannh@google.com, jeffxu@chromium.org, joey.gouly@arm.com,
kees@kernel.org, maz@kernel.org, pierre.langlois@arm.com,
qperret@google.com, ryan.roberts@arm.com, will@kernel.org,
linux-arm-kernel@lists.infradead.org, x86@kernel.org
Subject: Re: [RFC PATCH 08/16] mm: Introduce kernel_pgtables_set_pkey()
Date: Mon, 9 Dec 2024 11:03:35 +0100 [thread overview]
Message-ID: <20241209100335.GH21636@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20241206101110.1646108-9-kevin.brodsky@arm.com>
On Fri, Dec 06, 2024 at 10:11:02AM +0000, Kevin Brodsky wrote:
> kernel_pgtables_set_pkey() allows setting the pkey of all page table
> pages in swapper_pg_dir, recursively. This will be needed by
> kpkeys_hardened_pgtables, as it relies on all PTPs being mapped with
> a non-default pkey. Those initial kernel page tables cannot
> practically be assigned a non-default pkey right when they are
> allocated, so mutating them during (early) boot is required.
>
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> ---
>
> It feels that some sort of locking is called for in
> kernel_pgtables_set_pkey(), but I couldn't figure out what would be
> appropriate.
init_mm.page_table_lock is typically the one used to serialize kernel
page tables IIRC.
next prev parent reply other threads:[~2024-12-09 10:28 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 10:10 [RFC PATCH 00/16] pkeys-based page table hardening Kevin Brodsky
2024-12-06 10:10 ` [RFC PATCH 01/16] mm: Introduce kpkeys Kevin Brodsky
2024-12-06 10:10 ` [RFC PATCH 02/16] set_memory: Introduce set_memory_pkey() stub Kevin Brodsky
2024-12-06 10:10 ` [RFC PATCH 03/16] arm64: mm: Enable overlays for all EL1 indirect permissions Kevin Brodsky
2024-12-06 10:10 ` [RFC PATCH 04/16] arm64: Introduce por_set_pkey_perms() helper Kevin Brodsky
2024-12-06 10:10 ` [RFC PATCH 05/16] arm64: Implement asm/kpkeys.h using POE Kevin Brodsky
2024-12-06 10:11 ` [RFC PATCH 06/16] arm64: set_memory: Implement set_memory_pkey() Kevin Brodsky
2024-12-06 10:11 ` [RFC PATCH 07/16] arm64: Enable kpkeys Kevin Brodsky
2024-12-06 10:11 ` [RFC PATCH 08/16] mm: Introduce kernel_pgtables_set_pkey() Kevin Brodsky
2024-12-09 10:03 ` Peter Zijlstra [this message]
2024-12-10 9:27 ` Kevin Brodsky
2024-12-06 10:11 ` [RFC PATCH 09/16] mm: Introduce kpkeys_hardened_pgtables Kevin Brodsky
2024-12-06 10:11 ` [RFC PATCH 10/16] mm: Map page tables with privileged pkey Kevin Brodsky
2024-12-06 13:18 ` kernel test robot
2024-12-06 13:19 ` kernel test robot
2024-12-06 10:11 ` [RFC PATCH 11/16] arm64: kpkeys: Support KPKEYS_LVL_PGTABLES Kevin Brodsky
2024-12-06 10:11 ` [RFC PATCH 12/16] arm64: mm: Map p4d/pgd with privileged pkey Kevin Brodsky
2024-12-09 10:24 ` Peter Zijlstra
2024-12-10 9:27 ` Kevin Brodsky
2024-12-10 12:23 ` Peter Zijlstra
2024-12-11 13:35 ` Kevin Brodsky
2024-12-06 10:11 ` [RFC PATCH 13/16] arm64: mm: Reset pkey in __tlb_remove_table() Kevin Brodsky
2024-12-09 10:29 ` Peter Zijlstra
2024-12-10 9:28 ` Kevin Brodsky
2024-12-10 12:27 ` Peter Zijlstra
2024-12-11 13:37 ` Kevin Brodsky
2024-12-06 10:11 ` [RFC PATCH 14/16] arm64: mm: Guard page table writes with kpkeys Kevin Brodsky
2024-12-06 10:11 ` [RFC PATCH 15/16] arm64: Enable kpkeys_hardened_pgtables support Kevin Brodsky
2024-12-06 10:11 ` [RFC PATCH 16/16] mm: Add basic tests for kpkeys_hardened_pgtables Kevin Brodsky
2024-12-09 4:28 ` kernel test robot
2024-12-06 19:14 ` [RFC PATCH 00/16] pkeys-based page table hardening Jann Horn
2024-12-09 12:57 ` Kevin Brodsky
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=20241209100335.GH21636@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aruna.ramakrishna@oracle.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=jannh@google.com \
--cc=jeffxu@chromium.org \
--cc=joey.gouly@arm.com \
--cc=kees@kernel.org \
--cc=kevin.brodsky@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=pierre.langlois@arm.com \
--cc=qperret@google.com \
--cc=ryan.roberts@arm.com \
--cc=will@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.