From: Kevin Brodsky <kevin.brodsky@arm•com>
To: Linus Walleij <linusw@kernel•org>
Cc: linux-hardening@vger•kernel.org,
Andrew Morton <akpm@linux-foundation•org>,
Andy Lutomirski <luto@kernel•org>,
Catalin Marinas <catalin.marinas@arm•com>,
Dave Hansen <dave.hansen@linux•intel.com>,
"David Hildenbrand (Arm)" <david@kernel•org>,
Ira Weiny <ira.weiny@intel•com>, Jann Horn <jannh@google•com>,
Jeff Xu <jeffxu@chromium•org>, Joey Gouly <joey.gouly@arm•com>,
Kees Cook <kees@kernel•org>, Marc Zyngier <maz@kernel•org>,
Mark Brown <broonie@kernel•org>,
Matthew Wilcox <willy@infradead•org>,
Maxwell Bland <mbland@motorola•com>,
"Mike Rapoport (IBM)" <rppt@kernel•org>,
Peter Zijlstra <peterz@infradead•org>,
Pierre Langlois <pierre.langlois@arm•com>,
Quentin Perret <qperret@google•com>,
Rick Edgecombe <rick.p.edgecombe@intel•com>,
Ryan Roberts <ryan.roberts@arm•com>,
Vlastimil Babka <vbabka@kernel•org>,
Will Deacon <will@kernel•org>,
Yang Shi <yang@os•amperecomputing.com>,
Yeoreum Yun <yeoreum.yun@arm•com>,
linux-arm-kernel@lists•infradead.org, linux-mm@kvack•org,
x86@kernel•org, Lorenzo Stoakes <ljs@kernel•org>,
Thomas Gleixner <tglx@kernel•org>
Subject: Re: [PATCH RFC v8 01/24] mm: Introduce kpkeys
Date: Wed, 27 May 2026 10:24:02 +0200 [thread overview]
Message-ID: <b4eb4ea8-f4d6-4be2-81b1-4a8a46abe94e@arm.com> (raw)
In-Reply-To: <CAD++jLnURXzgAgkWCcYX0dLOLqHQw+gn96V1dzDa_0Aoi3430Q@mail.gmail.com>
On 26/05/2026 15:17, Linus Walleij wrote:
> Hi Kevin,
>
> here is just a few drive-by review comments pertaining to the
> API which will be used for all architectures wanting to use
> pkeys.
Appreciated, thanks!
> [...]
>
>> Because each architecture implementing pkeys uses a different
>> representation for the pkey register, and may reserve certain pkeys
>> for specific uses, support for kpkeys must be explicitly indicated
>> by selecting ARCH_HAS_KPKEYS and defining the following functions in
>> <asm/kpkeys.h>, in addition to the macros provided in
>> <asm-generic/kpkeys.h>:
>>
>> - arch_kpkeys_set_context()
>> - arch_kpkeys_restore_pkey_reg()
>> - arch_supports_kpkeys()
>>
>> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm•com>
> I'm following so far.
>
> Is there no need for something like
>
> ctx = arch_kpkeys_request_context(KEY_TYPE) ?
>
> I'm just thinking of the scenario that e.g. two architectures want
> to request the same type of key for some generic resource, but
> the underlying implementation is vastly different for the two
> architectures, so relying on hard-coded arch-specific constants
> may not work. I'm also thinking about archs supporting different
> versions/types of kpkeys in a multi-platform executable kernel
> that may execute on several different silicon with the same ISA.
I'm not sure I understand what potential limitations this is trying to
address. The only thing that is imposed by the framework is the value of
KPKEYS_CTX_*, which is purely symbolic. Everything else is up to the
architecture, including the value of each key (which could be determined
at runtime if needed) and the permissions associated to each context.
Conceptually a context is a set of permission overlays for all existing
keys, it doesn't have to be tied to just one key.
> Maybe this is too much upfront design, I understand it needs to
> be kept simple.
>
>> +#ifndef KPKEYS_PKEY_DEFAULT
>> +#define KPKEYS_PKEY_DEFAULT 0
>> +#endif
> (...)
>> +#define KPKEYS_CTX_DEFAULT 0
>> +
>> +#define KPKEYS_CTX_MIN KPKEYS_CTX_DEFAULT
>> +#define KPKEYS_CTX_MAX KPKEYS_CTX_DEFAULT
> I was thinking an enum:
>
> enum kpkey_type {
> KPKEY_DEFAULT = 0,
> KPKEY_MMU_TABLE = 1,
> ....
> };
>
> since this is what is used later.
>
>> +/**
>> + * kpkeys_set_context() - switch kpkeys context
>> + * @ctx: the context to switch to
>> + *
>> + * Switches to specified kpkeys context. @ctx must be a compile-time
>> + * constant. The arch-specific pkey register will be updated accordingly, and
>> + * the original value returned.
>> + *
>> + * Return: the original pkey register value if the register was written to, or
>> + * KPKEYS_PKEY_REG_INVAL otherwise (no write to the register was
>> + * required).
>> + */
>> +static __always_inline u64 kpkeys_set_context(int ctx)
> Should ctx be unsigned here? I'm nor sure what a negativ context
> would mean.
> kpkeys_set_context(unsigned int ctx)
That's a good point, now that we say "context" and not "level" an enum
would be a better representation. I would directly use:
u64 kpkeys_set_context(enum kpkeys_ctx ctx);
... unless we really need another layer of abstraction.
- Kevin
> And then I was thinking:
>
> unsigned int kpkeys_request_context(enum kpkey_type type) {}...
>
> + arch_ -prefixed version of the same.
>
> unsigned int ctx;
> ctx = kpkeys_request_context(KPKEY_MMU_TABLE);
> (...)
>
> Constant sinking in the compiler will optimize the arch
> function to a constant in the object code so it will still
> be fast just a bit more talkative in source form.
>
> Yours,
> Linus Walleij
next prev parent reply other threads:[~2026-05-27 8:24 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 11:15 [PATCH RFC v8 00/24] pkeys-based page table hardening Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 01/24] mm: Introduce kpkeys Kevin Brodsky
2026-05-26 13:17 ` Linus Walleij
2026-05-27 8:24 ` Kevin Brodsky [this message]
2026-05-26 11:15 ` [PATCH RFC v8 02/24] set_memory: Introduce set_memory_pkey() stub Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 03/24] arm64: mm: Enable overlays for all EL1 indirect permissions Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 04/24] arm64: Introduce por_elx_set_pkey_perms() helper Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 05/24] arm64: Implement asm/kpkeys.h using POE Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 06/24] arm64: set_memory: Implement set_memory_pkey() Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 07/24] arm64: Context-switch POR_EL1 Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 08/24] arm64: Initialize POR_EL1 register on cpu_resume() Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 09/24] arm64: Enable kpkeys Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 10/24] memblock: Move INIT_MEMBLOCK_* macros to header Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 11/24] mm: kpkeys: Introduce kpkeys_hardened_pgtables feature Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 12/24] mm: kpkeys: Protect regular page tables Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 13/24] mm: kpkeys: Introduce early page table allocator Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 14/24] mm: kpkeys: Protect vmemmap page tables Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 15/24] mm: kpkeys: Introduce hook for protecting static " Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 16/24] arm64: kpkeys: Implement arch_supports_kpkeys_early() Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 17/24] arm64: kpkeys: Support KPKEYS_CTX_PGTABLES Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 18/24] arm64: kpkeys: Ensure the linear map can be modified Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 19/24] arm64: kpkeys: Protect early page tables Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 20/24] arm64: kpkeys: Protect init_pg_dir Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 21/24] arm64: kpkeys: Guard page table writes Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 22/24] arm64: kpkeys: Batch KPKEYS_CTX_PGTABLES switches Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 23/24] arm64: kpkeys: Enable kpkeys_hardened_pgtables support Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 24/24] mm: Add basic tests for kpkeys_hardened_pgtables 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=b4eb4ea8-f4d6-4be2-81b1-4a8a46abe94e@arm.com \
--to=kevin.brodsky@arm$(echo .)com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=broonie@kernel$(echo .)org \
--cc=catalin.marinas@arm$(echo .)com \
--cc=dave.hansen@linux$(echo .)intel.com \
--cc=david@kernel$(echo .)org \
--cc=ira.weiny@intel$(echo .)com \
--cc=jannh@google$(echo .)com \
--cc=jeffxu@chromium$(echo .)org \
--cc=joey.gouly@arm$(echo .)com \
--cc=kees@kernel$(echo .)org \
--cc=linusw@kernel$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-hardening@vger$(echo .)kernel.org \
--cc=linux-mm@kvack$(echo .)org \
--cc=ljs@kernel$(echo .)org \
--cc=luto@kernel$(echo .)org \
--cc=maz@kernel$(echo .)org \
--cc=mbland@motorola$(echo .)com \
--cc=peterz@infradead$(echo .)org \
--cc=pierre.langlois@arm$(echo .)com \
--cc=qperret@google$(echo .)com \
--cc=rick.p.edgecombe@intel$(echo .)com \
--cc=rppt@kernel$(echo .)org \
--cc=ryan.roberts@arm$(echo .)com \
--cc=tglx@kernel$(echo .)org \
--cc=vbabka@kernel$(echo .)org \
--cc=will@kernel$(echo .)org \
--cc=willy@infradead$(echo .)org \
--cc=x86@kernel$(echo .)org \
--cc=yang@os$(echo .)amperecomputing.com \
--cc=yeoreum.yun@arm$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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