On 4/15/26 17:50, Kevin Brodsky wrote: > On 15/04/2026 15:00, David Hildenbrand (Arm) wrote: >> 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. > > That was originally the idea indeed, but in practice I don't expect > levels to have a strict ordering, as it's not practical for composing > features. > >> 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? > > Right, and in general a given level may be able to write to any number > of pkeys. That's why I don't want to conflate pkeys and levels. Agreed > that "level" might not be the clearest term though, since there's no > strict ordering.
As discussed offline, maybe the right terminology to use here would be something like a "context". You'd be activating/setting a context. KPKEY_CTX_DEFAULT KPKEY_CTX_PGTABLE KPKEY_CTX_SUPER_SECRET1 What is accessible (and how) is defined for each context. For example, I would assume that all context allow for read/write access to everything that KPKEY_CTX_DEFAULT has access to. -- Cheers, David
