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
