Re: [PATCH v6 01/30] mm: Introduce kpkeys

["David Hildenbrand (Arm)" <david@kernel.org>]

On 2/27/26 18:54, Kevin Brodsky wrote:
> 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 set and restore
> the pkey register and macros to define guard objects.
> 
> kpkeys introduces a new concept on top of pkeys: the kpkeys level.
> Each level is associated to a set of permissions for the pkeys
> managed by the kpkeys framework. kpkeys_set_level(lvl) sets those
> permissions according to lvl, and returns the original pkey
> register, to be later restored by kpkeys_restore_pkey_reg(). To
> start with, only KPKEYS_LVL_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).
> 
> 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>:

I don't quite understand the reason for using levels. Levels sounds like
it would all be in some ordered fashion, where higher levels have access
to lower levels.

Think of that as a key that can unlock all "lower" locks, not just a
single lock.

Then, the question is about the ordering once we introduce new
keys/locks. With two, it obviously doesn't matter :)

So naturally I wonder whether levels is really the right abstraction
here, and why we are not simply using "distinct" keys, like

KPKEY_DEFAULT
KPKEY_PGTABLE
KPKEY_SUPER_SECRET1
KPKEY_SUPER_SECRET2

Is it because you want KPKEY_PGTABLE also be able to write to KPKEY_DEFAULT?

But how would you handle KPKEY_SUPER_SECRET1 and KPKEY_SUPER_SECRET2 then?

-- 
Cheers,

David