diff options
| author | Linus Torvalds <torvalds@linux-foundation.org> | 2026-10-27 08:01:30 -1000 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2026-10-27 08:01:30 -1000 |
| commit | 62c457528529cdcfa32bc52b331ceca10f3937b6 (patch) | |
| tree | 996f24181b89b02cbc2afcbe74888590877e9639 /drivers/pci/hotplug/Kconfig | |
| parent | c60ebc3208b9ce1d8915318347962f7ce1dbd07d (diff) | |
| parent | 503b65da9a7e5447d91222f62399522f2f62a0fa (diff) | |
Pull vfs keyring updates from Christian Brauner:
"The kernel has two keyrings that userspace fills with X.509
certificates at boot: .fs-verity for fs-verity built-in signatures
and .dm-verity for dm-verity root hash signatures.
Neither is linked into any process keyring. Hence, request_key() and
KEYCTL_SEARCH can't find them. The only way for userspace to identify
them is to read their serial number out of /proc/keys. That is not
just a large file often the names can also be reused and appear
multiple times which allows forging these keyrings.
This adds two fixed special key ids, KEY_SPEC_DM_VERITY_KEYRING and
KEY_SPEC_FS_VERITY_KEYRING next to KEY_SPEC_BPF_KEYRING. The latter
went in through bpf-next this merge window.
lookup_user_key() resolves the fixed key ids to the two keyrings. So
userspace can add a dm-verity (fixed keyring id: -10) certificate with
keyctl padd asymmetric "" -10 < cert.der
and seal the keyring with
keyctl restrict_keyring -10
without looking anything up first"
* tag 'vfs-7.4-rc1.keyring' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
Documentation: keys: document IDs added since KEY_SPEC_REQKEY_AUTH_KEY
keys: add KEY_SPEC_FS_VERITY_KEYRING
keys: add KEY_SPEC_DM_VERITY_KEYRING
Diffstat (limited to 'drivers/pci/hotplug/Kconfig')
0 files changed, 0 insertions, 0 deletions
