[PATCH RFC v9 01/25] mm: Introduce kpkeys

[Kevin Brodsky]

On 07/09/2026 12:54, Mike Rapoport wrote:
> Hi Kevin,
>
>> kpkeys is a simple framework to enable the use of protection keys
>> (pkeys) to harden the kernel itself. This patch introduces the basic
>> API in <linux/kpkeys.h>: a couple of functions to enter/leave a
>> kpkeys context and macros to define guard objects.
>>
>> kpkeys introduces a new concept on top of pkeys: the kpkeys context.
>> Each context is associated with a set of permissions for the pkeys
>> managed by the kpkeys framework. kpkeys_enter_context(ctx) sets
>> those permissions according to ctx, and returns the original kpkeys
>> state (typically the arch-specific pkeys register) that is later
>> restored by calling kpkeys_leave_context(). To start with, only
>> KPKEYS_CTX_DEFAULT is available, which is meant to grant RW access
>> to KPKEYS_PKEY_DEFAULT (i.e. all memory since this is the only
>> available pkey for now).
>>
>> The underlying representation of each kpkeys context is entirely
>> architecture-specific. Support for kpkeys must be explicitly
>> indicated by selecting ARCH_HAS_KPKEYS and defining the following
>> functions in <asm/kpkeys.h>:
>>
>> * arch_kpkeys_enter_context()
>> * arch_kpkeys_leave_context()
>> * arch_supports_kpkeys()
>>
>> Additionally, <asm/kpkeys_types.h> must define struct arch_kpkeys_state,
>> which typically provides storage for the pkeys register.
>>
>> Signed-off-by: Kevin Brodsky <kevin.brodsky at arm.com>
>>
>> diff --git a/include/linux/kpkeys.h b/include/linux/kpkeys.h
>> new file mode 100644
>> index 0000000000000..eac522f552141
>> --- /dev/null
>> +++ b/include/linux/kpkeys.h
>> @@ -0,0 +1,104 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +#ifndef _LINUX_KPKEYS_H
>> +#define _LINUX_KPKEYS_H
>> +
>> +#include <linux/bug.h>
>> +#include <linux/cleanup.h>
>> +#include <linux/kpkeys_types.h>
>> +
>> +/**
>> + * KPKEYS_GUARD_NOOP() - define a guard type that does nothing
> Nit: I'd suggest to drop "define" from all the descriptions, they would
> read better without it IMHO.

Fair enough, but if we say just "a guard type that does nothing" is it
clear that this is a macro defining a type, and not a type itself?

- Kevin