Re: [GIT PULL for v7.4] vfs keyring

From: Christian Brauner

Date: Mon Oct 26 2026 - 16:36:04 EST


On Mon, Oct 26, 2026 at 10:10:54AM -0400, James Bottomley wrote:
> On Sat, 2026-10-24 at 12:44 +0200, Christian Brauner wrote:
> > Hey Linus,
> >
> > This is a delayed pull request which was waiting for the bpf merge.
> > This used a shared branch.
> >
> > /* Summary */
> > This adds well-known key ids for the .dm-verity and .fs-verity
> > keyrings.
> >
> > Neither keyring is linked into any other keyring so request_key() and
> > KEYCTL_SEARCH can't find them. Userspace has to scrape the serial out
> > of /proc/keys before it can add a key to either of them. That's not
> > great as any user can add a key with a newline in its description and
> > make /proc/keys show a fake .dm-verity keyring line with whatever
> > serial they like.
> >
> > /* Testing */
> >
> > No build failures or warnings were observed.
> >
> > /* Conflicts */
> >
> > Merge conflicts with mainline
> > =============================
> >
> > No known conflicts.
> >
> > Merge conflicts with other trees
> > ================================
> >
> > No known conflicts.
> >
> > The following changes since commit
> > 1b7415bf70be95b9a1e7e87d544867881065613f:
> >
> >   Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 7.3-rc2
> > (2026-09-06 16:17:40 -0700)
> >
> > are available in the Git repository at:
> >
> >   git@xxxxxxxxxxxxxxxxxxx:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-
> > 7.4-rc1.keyring
> >
> > for you to fetch changes up to
> > 503b65da9a7e5447d91222f62399522f2f62a0fa:
> >
> >   Merge patch series "keys: Add well known IDs for fs-verity/dm-
> > verity keys" (2026-10-12 23:37:42 +0200)
> >
> > ----------------------------------------------------------------
> > vfs-7.4-rc1.keyring
> >
> > Please consider pulling these changes from the signed vfs-7.4-
> > rc1.keyring tag.
> >
> > Thanks!
> > Christian
> >
> > ----------------------------------------------------------------
> > 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
>
> It would actually have been nice to copy the keyrings list and
> maintainers on this. I don't think there's an objection but not cc'ing
> the list and maintainers makes it look like some type of end run.

Uhm, they were?...

From: Andrew Halaney <andrew@xxxxxxxxxxxx>
To: Alexei Starovoitov <ast@xxxxxxxxxx>, Daniel Borkmann <daniel@xxxxxxxxxxxxx>, Andrii Nakryiko <andrii@xxxxxxxxxx>, Alasdair Kergon <agk@xxxxxxxxxx>, Mike
Snitzer <snitzer@xxxxxxxxxx>, Mikulas Patocka <mpatocka@xxxxxxxxxx>, Benjamin Marzinski <bmarzins@xxxxxxxxxx>, David Howells <dhowells@xxxxxxxxxx>,
Jarkko Sakkinen <jarkko@xxxxxxxxxx>, Paul Moore <paul@xxxxxxxxxxxxxx>, James Morris <jmorris@xxxxxxxxx>, "Serge E. Hallyn" <serge@xxxxxxxxxx>, Eric
Biggers <ebiggers@xxxxxxxxxx>, "Theodore Y. Ts'o" <tytso@xxxxxxx>, Jonathan Corbet <corbet@xxxxxxx>, Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>, Randy
Dunlap <rdunlap@xxxxxxxxxxxxx>
Cc: dm-devel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, keyrings@xxxxxxxxxxxxxxx, linux-security-module@xxxxxxxxxxxxxxx, bpf@xxxxxxxxxxxxxxx,
^^^^^^^^^^^^^^^^^^^^^^^^
fsverity@xxxxxxxxxxxxxxx, linux-doc@xxxxxxxxxxxxxxx, Andrew Halaney <andrew@xxxxxxxxxxxx>, "Christian Brauner (Amutable)" <brauner@xxxxxxxxxx>
Subject: [PATCH bpf-next v2 0/3] keys: Add well known IDs for fs-verity/dm-verity keys
Message-Id: <20261008-ajhalaney-dmverity-key-identifier-v2-0-008456d189cb@xxxxxxxxxxxx>

> > Christian Brauner (2):
> >       Merge bpf keyring work from of
> > git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next
> >       Merge patch series "keys: Add well known IDs for fs-verity/dm-
> > verity keys"
>
> This is a bit nasty because the keyring specs get renumbered inside the
> merges ... it would have been much clearer to people looking at the
> history if the patches were rebased instead.

Nothing got renumbered. Both merges are clean.
The only commits that touch the ids are Daniel's bpf one adding -9 in
bpf-next and Andrew's two adding -10 and -11. The branch is the three
patches on top of the bits shared with bpf-next with an explanation why
this was needed.

A rebase would given the same commit but would've meant invalidating
things that were already in -next.