[PATCH bpf-next v2 0/3] keys: Add well known IDs for fs-verity/dm-verity keys

[PATCH bpf-next v2 0/3] keys: Add well known IDs for fs-verity/dm-verity keys

[Andrew Halaney]

This more or less follows the bpf keyring approach, allowing userspace
to easily find the keys instead of having to parse /proc/keys.

Signed-off-by: Andrew Halaney <andrew@amutable.com>
---
Changes in v2:
- Rebased / target bpf-next/for-next since 264d8fd2794f ("bpf, keys: Add a bpf
  keyring for program signature validation") only exists there.
- Grabbed Reviewed-by trailers.
- Link to v1: https://lore.kernel.org/r/20260914-ajhalaney-dmverity-key-identifier-v1-0-01922dc1366a@amutable.com

---
Andrew Halaney (3):
      keys: add KEY_SPEC_DM_VERITY_KEYRING
      keys: add KEY_SPEC_FS_VERITY_KEYRING
      Documentation: keys: document IDs added since KEY_SPEC_REQKEY_AUTH_KEY

 Documentation/security/keys/core.rst | 13 ++++++++
 drivers/md/dm-verity-verify-sig.c    |  3 ++
 fs/verity/signature.c                |  2 ++
 include/linux/key.h                  |  2 ++
 include/uapi/linux/keyctl.h          |  2 ++
 security/keys/process_keys.c         | 58 ++++++++++++++++++++++++++++++++++++
 6 files changed, 80 insertions(+)
---
base-commit: e1d84a37cba984388988d2f1ddc84561413f0db2
change-id: 20260914-ajhalaney-dmverity-key-identifier-4187b6233be5

Best regards,
-- 
Andrew Halaney <andrew@amutable.com>

[PATCH bpf-next v2 1/3] keys: add KEY_SPEC_DM_VERITY_KEYRING

[Andrew Halaney]

The .dm-verity keyring is not linked into any process keyring, so
request_key() and KEYCTL_SEARCH cannot find it. Userspace has to scrape
/proc/keys for the serial to use.

That's not great, one could put in a bogus description containing
a newline to confuse userspace further. For example, thanks to AI
models, which I run as root but you could show off as any old user:

    # DESC=$'.dm-verity: 1\n0badf00d I--Q---     1 perm 082f0000     0     0 keyring   .dm-verity'
    # k=$(echo -n "1234567" | keyctl padd user "$DESC" @s)
    # keyctl setperm "$k" 0x3f010001

    # cat /proc/keys | grep dm-verity
    10402023 I------     2 perm 082f0000     0     0 keyring   .dm-verity: empty
    12e0bee6 I--Q---     1 perm 3f010001     0     0 user      .dm-verity: 1
    0badf00d I--Q---     1 perm 082f0000     0     0 keyring   .dm-verity: 7

0x0badf00d is not a keyring, it is the text inside our user's key
description. Telling the two apart needs a KEYCTL_DESCRIBE per row
which is annoying to do. i.e.:

    # keyctl rdescribe 0x10402023
    keyring;0;0;082f0000;.dm-verity
    # keyctl rdescribe 0x0badf00d
    keyctl_describe: Required key not available

Let's just give it a well known identifier, i.e.:

    # keyctl rdescribe -10
    keyring;0;0;082f0000;.dm-verity

This is exactly what
commit 264d8fd2794f ("bpf, keys: Add a bpf keyring for program signature validation")
did, and was the inspiration for this commit minus the spinlock bits
required due to dm-verity being a module.

Suggested-by: Christian Brauner (Amutable) <brauner@kernel.org>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
Signed-off-by: Andrew Halaney <andrew@amutable.com>
---
 drivers/md/dm-verity-verify-sig.c |  3 +++
 include/linux/key.h               |  1 +
 include/uapi/linux/keyctl.h       |  1 +
 security/keys/process_keys.c      | 33 +++++++++++++++++++++++++++++++++
 4 files changed, 38 insertions(+)

diff --git a/drivers/md/dm-verity-verify-sig.c b/drivers/md/dm-verity-verify-sig.c
index b2b55c41e2cb..da509dcdd7e5 100644
--- a/drivers/md/dm-verity-verify-sig.c
+++ b/drivers/md/dm-verity-verify-sig.c
@@ -189,11 +189,14 @@ int __init dm_verity_verify_sig_init(void)
 	    keyring_restrict(make_key_ref(dm_verity_keyring, true), NULL, NULL))
 		panic("dm-verity can't seal keyring\n");
 
+	key_register_dm_verity_keyring(dm_verity_keyring);
+
 	return 0;
 }
 
 void dm_verity_verify_sig_exit(void)
 {
+	key_register_dm_verity_keyring(NULL);
 	key_revoke(dm_verity_keyring);
 	key_put(dm_verity_keyring);
 }
diff --git a/include/linux/key.h b/include/linux/key.h
index bd10fe45819d..ae8d3314fd93 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -441,6 +441,7 @@ extern int keyring_restrict(key_ref_t keyring, const char *type,
 			    const char *restriction);
 
 extern void key_register_bpf_keyring(struct key *keyring);
+extern void key_register_dm_verity_keyring(struct key *keyring);
 
 extern struct key *key_lookup(key_serial_t id);
 
diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
index fa85b9760391..75923941f1b3 100644
--- a/include/uapi/linux/keyctl.h
+++ b/include/uapi/linux/keyctl.h
@@ -25,6 +25,7 @@
 #define KEY_SPEC_REQKEY_AUTH_KEY	-7	/* - key ID for assumed request_key auth key */
 #define KEY_SPEC_REQUESTOR_KEYRING	-8	/* - key ID for request_key() dest keyring */
 #define KEY_SPEC_BPF_KEYRING		-9	/* - key ID for the BPF-specific keyring */
+#define KEY_SPEC_DM_VERITY_KEYRING	-10	/* - key ID for the .dm-verity keyring */
 
 /* request-key default keyrings */
 #define KEY_REQKEY_DEFL_NO_CHANGE		-1
diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
index 44358388e395..dba3df41638b 100644
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -25,6 +25,10 @@ static DEFINE_MUTEX(key_session_mutex);
 /* BPF keyring reachable through KEY_SPEC_BPF_KEYRING */
 static struct key *bpf_keyring __ro_after_init;
 
+/* dm-verity keyring reachable through KEY_SPEC_DM_VERITY_KEYRING */
+static struct key *dm_verity_keyring;
+static DEFINE_SPINLOCK(dm_verity_keyring_lock);
+
 /* The root user's tracking struct */
 struct key_user root_key_user = {
 	.usage		= REFCOUNT_INIT(3),
@@ -607,6 +611,24 @@ void key_register_bpf_keyring(struct key *keyring)
 	bpf_keyring = keyring;
 }
 
+/**
+ * key_register_dm_verity_keyring - Publish the keyring for KEY_SPEC_DM_VERITY_KEYRING
+ * @keyring: The keyring to publish, or NULL to withdraw it
+ *
+ * Make @keyring reachable by userspace through the KEY_SPEC_DM_VERITY_KEYRING
+ * special key ID, so that provisioning it does not require scraping its
+ * serial out of /proc/keys first. dm-verity can be unloaded as a module
+ * and the keyring deregistered, as such serialize access with
+ * dm_verity_keyring_lock.
+ */
+void key_register_dm_verity_keyring(struct key *keyring)
+{
+	spin_lock(&dm_verity_keyring_lock);
+	dm_verity_keyring = keyring;
+	spin_unlock(&dm_verity_keyring_lock);
+}
+EXPORT_SYMBOL_GPL(key_register_dm_verity_keyring);
+
 /*
  * Look up a key ID given us by userspace with a given permissions mask to get
  * the key it refers to.
@@ -766,6 +788,17 @@ key_ref_t lookup_user_key(key_serial_t id, unsigned long lflags,
 		key_ref = make_key_ref(key, 0);
 		break;
 
+	case KEY_SPEC_DM_VERITY_KEYRING:
+		spin_lock(&dm_verity_keyring_lock);
+		key = dm_verity_keyring;
+		if (key)
+			__key_get(key);
+		spin_unlock(&dm_verity_keyring_lock);
+		if (!key)
+			goto error;
+		key_ref = make_key_ref(key, 0);
+		break;
+
 	default:
 		key_ref = ERR_PTR(-EINVAL);
 		if (id < 1)

-- 
2.55.0

Re: [PATCH bpf-next v2 1/3] keys: add KEY_SPEC_DM_VERITY_KEYRING

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]

> keys: add KEY_SPEC_DM_VERITY_KEYRING

TL;DR: Design/uapi question: was David Howells' v1 suggestion (reserved
negative key ID block, common register functions) intentionally dropped? The
new uapi value -10 should be settled before release.

> diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
> --- a/include/uapi/linux/keyctl.h
> +++ b/include/uapi/linux/keyctl.h
> @@ -25,6 +25,7 @@
>  #define KEY_SPEC_REQKEY_AUTH_KEY	-7	/* - key ID for assumed request_key auth key */
>  #define KEY_SPEC_REQUESTOR_KEYRING	-8	/* - key ID for request_key() dest keyring */
>  #define KEY_SPEC_BPF_KEYRING		-9	/* - key ID for the BPF-specific keyring */
> +#define KEY_SPEC_DM_VERITY_KEYRING	-10	/* - key ID for the .dm-verity keyring */

On v1, David Howells wrote:

  I have no particular objection to setting aside a block of negative key
  IDs for special keyrings that need to be accessed a lot - though I would
  make common reg/unreg functions that take the ID to be registered and,
  say, set the block at -257..-512.  Moving the BFP keyring to -257 and
  DM to -258.

  (<715249.1789718726@warthog.procyon.org.uk>)

The question of whether this was being asked for v2 was raised in reply, but
there was no answer, and this version still continues the one-off -9/-10
sequence with a dm-verity specific key_register_dm_verity_keyring() and
dm_verity_keyring_lock.

Was the suggestion to use a reserved ID block with common register and
unregister functions intentionally dropped, or should it still be addressed?

Since KEY_SPEC_DM_VERITY_KEYRING is a UAPI value, would it be possible to
settle this before the -10 value is released?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/37844805282

Re: [PATCH bpf-next v2 1/3] keys: add KEY_SPEC_DM_VERITY_KEYRING

[Andrew Halaney]

On Thu, Oct 08, 2026 at 09:44:46PM +0000, bot+bpf-ci@kernel.org wrote:
> > keys: add KEY_SPEC_DM_VERITY_KEYRING
> 
> TL;DR: Design/uapi question: was David Howells' v1 suggestion (reserved
> negative key ID block, common register functions) intentionally dropped? The
> new uapi value -10 should be settled before release.
> 
> > diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
> > --- a/include/uapi/linux/keyctl.h
> > +++ b/include/uapi/linux/keyctl.h
> > @@ -25,6 +25,7 @@
> >  #define KEY_SPEC_REQKEY_AUTH_KEY	-7	/* - key ID for assumed request_key auth key */
> >  #define KEY_SPEC_REQUESTOR_KEYRING	-8	/* - key ID for request_key() dest keyring */
> >  #define KEY_SPEC_BPF_KEYRING		-9	/* - key ID for the BPF-specific keyring */
> > +#define KEY_SPEC_DM_VERITY_KEYRING	-10	/* - key ID for the .dm-verity keyring */
> 
> On v1, David Howells wrote:
> 
>   I have no particular objection to setting aside a block of negative key
>   IDs for special keyrings that need to be accessed a lot - though I would
>   make common reg/unreg functions that take the ID to be registered and,
>   say, set the block at -257..-512.  Moving the BFP keyring to -257 and
>   DM to -258.
> 
>   (<715249.1789718726@warthog.procyon.org.uk>)
> 
> The question of whether this was being asked for v2 was raised in reply, but
> there was no answer, and this version still continues the one-off -9/-10
> sequence with a dm-verity specific key_register_dm_verity_keyring() and
> dm_verity_keyring_lock.
> 
> Was the suggestion to use a reserved ID block with common register and
> unregister functions intentionally dropped, or should it still be addressed?
> 
> Since KEY_SPEC_DM_VERITY_KEYRING is a UAPI value, would it be possible to
> settle this before the -10 value is released?
> 

With the BPF keyring ID already being merged here in bpf-next, plus
Jarkko's feedback/RB, I continued following the current pattern instead of
walking back the BPF keyring ID, and dealing with the
builtin/module/rodata differences I alluded to that would make that
approach a little more annoying (at least with how I thought it thru).

> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/37844805282

Re: [PATCH bpf-next v2 1/3] keys: add KEY_SPEC_DM_VERITY_KEYRING

[Manuel Huber]

On Thu, Oct 08, 2026 at 02:57:00PM -0700, Andrew Halaney wrote:
> With the BPF keyring ID already being merged here in bpf-next, plus
> Jarkko's feedback/RB, I continued following the current pattern instead
> of walking back the BPF keyring ID, and dealing with the
> builtin/module/rodata differences I alluded to that would make that
> approach a little more annoying (at least with how I thought it thru).

Another data point for this design choice: after initial discussions
with Fan Wu, I am about to propose a dedicated .ipe keyring for IPE
policy-signature verification. The keyring would be exposed to
userspace so that a trusted entity can provision keys, modeled after
the .dm-verity keyring.

I do not want to introduce churn to this discussion. I am happy to
establish the reserved ID range and generic registration interface
upon proposing my changeset, to establish this separately, or to
follow any other suggestions. Getting guidance for this subject ahead
of time for the case where 'yet another keyring' is introduced would be
highly appreciated.

Re: [PATCH bpf-next v2 1/3] keys: add KEY_SPEC_DM_VERITY_KEYRING

[Christian Brauner]

On Sun, Oct 11, 2026 at 09:35:43AM +0000, Manuel Huber wrote:
> On Thu, Oct 08, 2026 at 02:57:00PM -0700, Andrew Halaney wrote:
> > With the BPF keyring ID already being merged here in bpf-next, plus
> > Jarkko's feedback/RB, I continued following the current pattern instead
> > of walking back the BPF keyring ID, and dealing with the
> > builtin/module/rodata differences I alluded to that would make that
> > approach a little more annoying (at least with how I thought it thru).
> 
> Another data point for this design choice: after initial discussions
> with Fan Wu, I am about to propose a dedicated .ipe keyring for IPE
> policy-signature verification. The keyring would be exposed to
> userspace so that a trusted entity can provision keys, modeled after
> the .dm-verity keyring.
> 
> I do not want to introduce churn to this discussion. I am happy to
> establish the reserved ID range and generic registration interface
> upon proposing my changeset, to establish this separately, or to
> follow any other suggestions. Getting guidance for this subject ahead
> of time for the case where 'yet another keyring' is introduced would be
> highly appreciated.

I think another keyring for just .ipe is fine if they want that. I
wonder what you use ipe for. I've implemented ipe via a simple bpf lsm
in userspace (well, for dm-verity. We don't use IMA or fsverity.). It's
available in systemd itself. 

Re: [PATCH bpf-next v2 1/3] keys: add KEY_SPEC_DM_VERITY_KEYRING

[Manuel Huber]

On Mon, Oct 12, 2026 at 03:12:53PM +0200, Christian Brauner wrote:
> I think another keyring for just .ipe is fine if they want that. I
> wonder what you use ipe for. I've implemented ipe via a simple bpf lsm
> in userspace (well, for dm-verity. We don't use IMA or fsverity.). It's
> available in systemd itself.

Thanks, Christian, for bringing this onto my radar. Initially, I was
only seeking input on how to address David Howells' point about the
one-off sequence for assigning key IDs for the case I would introduce
a new IPE keyring (i.e. whether to use -12 and continue with the
existing pattern under question or to shift to introducing a dedicated
key range such as -257..-512). However, the excellent point you're
raising may indeed possibly allow me to achieve my goals without
leveraging IPE at all, building a BPF based mechanism instead.

My scenario: Kata Containers runs Kubernetes pods in ephemeral,
headless VMs. When pods are scheduled via kubelet, containerd, and the
Kata shim on the host cause a pod VM to be launched inside which the
Kata agent creates and runs the workload containers. The Kata stack has
various flavor variants. The variant I am trying to harden is disabling
filesystem sharing between host and guest VM and cold-plugging rootfs
disk(s) for the guest VM at launch time (Kata agent sits in the rootfs).
These disks are dm-verity protected; the kernel directly boots into the
rootfs without an initramfs using verity kernel command line parameters.
In systemd-less Kata flavors, Kata agent runs as the initial process,
and waits for CreateContainer requests. Creating and starting containers
requires a transport for container image layers from host to guest. This
variant uses containerd's erofs snapshotter which provides dm-verity
protected image layers. The Kata shim hot-plugs these image layers as a
single block device (VMDK+GPT). Today, the kata-agent mounts each layer
found in that disk using dm-verity.
My goal is to enforce strict code integrity for these guests, and that
can be achieved because all code we expect to be executed resides on
dm-verity protected r/o mounts. Obviously, this requires users to be
aware that they can no longer dynamically acquire code and run it from
a tmpfs.

My idea so far was to leverage IPE to enforce code integrity. However,
the current IPE model does not yet apply well for my scenario, mainly
because the container image layer root hashes (and their signatures) to
be used are not known ahead of time, so I cannot bake in a static
IPE policy. The idea was thus to allow trusted userspace to provision
an IPE policy. For this, kata-agent would dynamically create a key
pair. Before starting workloads (and thus transitioning to an untrusted
state), kata-agent would populate and restrict the IPE keyring, author,
sign, load and enforce the IPE policy. At this point in time, all
dm-verity devices are mounted.
For this, the first step would be to establish the IPE keyring.
I was additionally going to introduce a 'sealing' mechanism for IPE as
a separate contribution: right before kata-agent starts the workload
containers, the agent seals the IPE policy. I was going to express this
within IPE itself, blocking alterations to the IPE policy via
securityfs. The sealing would be expressed via IPE policy definitions,
e.g., "op=IPE_ENFORCEMENT_OFF action=DENY", or
"op=IPE_POLICY_UPDATE action=DENY", so this way not even a privileged
workload with CAP_MAC_ADMIN would be able to tamper with the policy.
This was a brief as possible explanation, may lack context and details,
but I hope the general idea made sense.

[PATCH bpf-next v2 2/3] keys: add KEY_SPEC_FS_VERITY_KEYRING

[Andrew Halaney]

Same problem as the dm-verity keyring: .fs-verity is allocated unlinked,
so the only way for userspace to name it is to scrape /proc/keys.

Suggested-by: Christian Brauner (Amutable) <brauner@kernel.org>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
Signed-off-by: Andrew Halaney <andrew@amutable.com>
---
 fs/verity/signature.c        |  2 ++
 include/linux/key.h          |  1 +
 include/uapi/linux/keyctl.h  |  1 +
 security/keys/process_keys.c | 25 +++++++++++++++++++++++++
 4 files changed, 29 insertions(+)

diff --git a/fs/verity/signature.c b/fs/verity/signature.c
index 0302a4e506ec..07657e913b22 100644
--- a/fs/verity/signature.c
+++ b/fs/verity/signature.c
@@ -135,4 +135,6 @@ void __init fsverity_init_signature(void)
 			      KEY_ALLOC_NOT_IN_QUOTA, NULL, NULL);
 	if (IS_ERR(fsverity_keyring))
 		panic("failed to allocate \".fs-verity\" keyring");
+
+	key_register_fs_verity_keyring(fsverity_keyring);
 }
diff --git a/include/linux/key.h b/include/linux/key.h
index ae8d3314fd93..dd386c56278c 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -442,6 +442,7 @@ extern int keyring_restrict(key_ref_t keyring, const char *type,
 
 extern void key_register_bpf_keyring(struct key *keyring);
 extern void key_register_dm_verity_keyring(struct key *keyring);
+extern void key_register_fs_verity_keyring(struct key *keyring);
 
 extern struct key *key_lookup(key_serial_t id);
 
diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
index 75923941f1b3..00cc0942203e 100644
--- a/include/uapi/linux/keyctl.h
+++ b/include/uapi/linux/keyctl.h
@@ -26,6 +26,7 @@
 #define KEY_SPEC_REQUESTOR_KEYRING	-8	/* - key ID for request_key() dest keyring */
 #define KEY_SPEC_BPF_KEYRING		-9	/* - key ID for the BPF-specific keyring */
 #define KEY_SPEC_DM_VERITY_KEYRING	-10	/* - key ID for the .dm-verity keyring */
+#define KEY_SPEC_FS_VERITY_KEYRING	-11	/* - key ID for the .fs-verity keyring */
 
 /* request-key default keyrings */
 #define KEY_REQKEY_DEFL_NO_CHANGE		-1
diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
index dba3df41638b..655c58a96fcb 100644
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -29,6 +29,9 @@ static struct key *bpf_keyring __ro_after_init;
 static struct key *dm_verity_keyring;
 static DEFINE_SPINLOCK(dm_verity_keyring_lock);
 
+/* fs-verity keyring reachable through KEY_SPEC_FS_VERITY_KEYRING */
+static struct key *fs_verity_keyring __ro_after_init;
+
 /* The root user's tracking struct */
 struct key_user root_key_user = {
 	.usage		= REFCOUNT_INIT(3),
@@ -629,6 +632,20 @@ void key_register_dm_verity_keyring(struct key *keyring)
 }
 EXPORT_SYMBOL_GPL(key_register_dm_verity_keyring);
 
+/**
+ * key_register_fs_verity_keyring - Publish the keyring for KEY_SPEC_FS_VERITY_KEYRING
+ * @keyring: The keyring to publish
+ *
+ * Make @keyring reachable by userspace through the KEY_SPEC_FS_VERITY_KEYRING
+ * special key ID, so that provisioning it does not require scraping its
+ * serial out of /proc/keys first. Called once, from an initcall, and never
+ * undone.
+ */
+void key_register_fs_verity_keyring(struct key *keyring)
+{
+	fs_verity_keyring = keyring;
+}
+
 /*
  * Look up a key ID given us by userspace with a given permissions mask to get
  * the key it refers to.
@@ -799,6 +816,14 @@ key_ref_t lookup_user_key(key_serial_t id, unsigned long lflags,
 		key_ref = make_key_ref(key, 0);
 		break;
 
+	case KEY_SPEC_FS_VERITY_KEYRING:
+		key = fs_verity_keyring;
+		if (!key)
+			goto error;
+		__key_get(key);
+		key_ref = make_key_ref(key, 0);
+		break;
+
 	default:
 		key_ref = ERR_PTR(-EINVAL);
 		if (id < 1)

-- 
2.55.0

[PATCH bpf-next v2 3/3] Documentation: keys: document IDs added since KEY_SPEC_REQKEY_AUTH_KEY

[Andrew Halaney]

The table of special key IDs stops at KEY_SPEC_REQKEY_AUTH_KEY.
Fill in all the new ones.

Suggested-by: Christian Brauner (Amutable) <brauner@kernel.org>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
Signed-off-by: Andrew Halaney <andrew@amutable.com>
---
 Documentation/security/keys/core.rst | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst
index 326b8a973828..37ed42382f16 100644
--- a/Documentation/security/keys/core.rst
+++ b/Documentation/security/keys/core.rst
@@ -372,6 +372,19 @@ process making the call::
 	KEY_SPEC_GROUP_KEYRING		-6	GID-specific keyring
 	KEY_SPEC_REQKEY_AUTH_KEY	-7	assumed request_key()
 						  authorisation key
+	KEY_SPEC_REQUESTOR_KEYRING	-8	request_key() destination
+						  keyring
+
+There are also values that refer to a specific kernel keyring rather than to
+anything belonging to the caller.  These keyrings are not linked into any
+keyring, so a search cannot reach them and the ID is the only way to name
+one::
+
+	CONSTANT			VALUE	KEY REFERENCED
+	==============================	======	===========================
+	KEY_SPEC_BPF_KEYRING		-9	the ".bpf" keyring
+	KEY_SPEC_DM_VERITY_KEYRING	-10	the ".dm-verity" keyring
+	KEY_SPEC_FS_VERITY_KEYRING	-11	the ".fs-verity" keyring
 
 
 The main syscalls are:

-- 
2.55.0

Re: [PATCH bpf-next v2 0/3] keys: Add well known IDs for fs-verity/dm-verity keys

[Christian Brauner]

On Thu, 08 Oct 2026 15:57:34 -0500, Andrew Halaney wrote:
> This more or less follows the bpf keyring approach, allowing userspace
> to easily find the keys instead of having to parse /proc/keys.

Applied to the vfs-7.4.keyring branch of the vfs/vfs.git tree.
Patches in the vfs-7.4.keyring branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-7.4.keyring

[1/3] keys: add KEY_SPEC_DM_VERITY_KEYRING
      https://git.kernel.org/vfs/vfs/c/d3b8a0988385
[2/3] keys: add KEY_SPEC_FS_VERITY_KEYRING
      https://git.kernel.org/vfs/vfs/c/8439e5c46c33
[3/3] Documentation: keys: document IDs added since KEY_SPEC_REQKEY_AUTH_KEY
      https://git.kernel.org/vfs/vfs/c/b553f7d131ed