From: Jarkko Sakkinen <jarkko@kernel.org>
To: Andrew Halaney <andrew@amutable.com>
Cc: Alasdair Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>,
Benjamin Marzinski <bmarzins@redhat.com>,
David Howells <dhowells@redhat.com>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Eric Biggers <ebiggers@kernel.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
bpf@vger.kernel.org, fsverity@lists.linux.dev,
linux-doc@vger.kernel.org,
"Christian Brauner (Amutable)" <brauner@kernel.org>
Subject: Re: [PATCH 1/3] keys: add KEY_SPEC_DM_VERITY_KEYRING
Date: Fri, 18 Sep 2026 05:29:29 +0300 [thread overview]
Message-ID: <aqyiCavj3xeNqyAo@kernel.org> (raw)
In-Reply-To: <20260914-ajhalaney-dmverity-key-identifier-v1-1-01922dc1366a@amutable.com>
On Mon, Sep 14, 2026 at 11:41:42AM -0500, Andrew Halaney wrote:
> 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.
This is great for discussion but what we want for the commit message
is just motivation and resolution.
I don't think we need all this just to say that /proc/keys in a racy
query mechanism for production, which is an issue for dm-verity, given
that nothing else is available.
And secondly special keys are meant for implicit keyrings so isn't
that all there's to it?
>
> Suggested-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
>
BR, Jarkko
next prev parent reply other threads:[~2026-09-18 2:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 16:41 [PATCH 0/3] keys: Add well known IDs for fs-verity/dm-verity keys Andrew Halaney
2026-09-14 16:41 ` [PATCH 1/3] keys: add KEY_SPEC_DM_VERITY_KEYRING Andrew Halaney
2026-09-18 2:29 ` Jarkko Sakkinen [this message]
2026-09-18 8:05 ` David Howells
2026-09-18 19:59 ` Andrew Halaney
2026-09-14 16:41 ` [PATCH 2/3] keys: add KEY_SPEC_FS_VERITY_KEYRING Andrew Halaney
2026-09-14 16:41 ` [PATCH 3/3] Documentation: keys: document IDs added since KEY_SPEC_REQKEY_AUTH_KEY Andrew Halaney
2026-09-15 12:39 ` [PATCH 0/3] keys: Add well known IDs for fs-verity/dm-verity keys Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aqyiCavj3xeNqyAo@kernel.org \
--to=jarkko@kernel.org \
--cc=agk@redhat.com \
--cc=andrew@amutable.com \
--cc=bmarzins@redhat.com \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=dhowells@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=ebiggers@kernel.org \
--cc=fsverity@lists.linux.dev \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=paul@paul-moore.com \
--cc=rdunlap@infradead.org \
--cc=serge@hallyn.com \
--cc=skhan@linuxfoundation.org \
--cc=snitzer@kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®