On 10/4/26 7:29 PM, Eric Biggers wrote:
On Sun, Oct 04, 2026 at 09:44:57AM +0200, Milan Broz wrote:
On 10/2/26 10:14 PM, Eric Biggers wrote:
...
From what I understand, the point of the keyring support in
dm-{crypt,inlinecrypt,integrity} is:
- To support "trusted" keys. But that is not what was actually
implemented in dm-inlinecrypt.
- To avoid having the key be readable with STATUSTYPE_TABLE. But that
is not what was actually implemented in dm-inlinecrypt. Keyrings are
also unnecesary to solve that problem.
There is more to that
- to avoid key cached in dm-crypt (or other target)
(dmsetup must be able to retrieve mapping table in the form directly
reusable for recreating DM mapping, so raw key must be available)
It's of course still there anyway, so that the data can be encrypted or
decrypted. crypt_config::cipher_tfm for dm-crypt, inlinecrypt_ctx::key
for dm-inlinecrypt, or dm_integrity_c::internal_shash for dm-integrity.
Raw key is then not part of internal dm-crypt structures, that was the point.
Crypto API needs key, obviously. I did not check recent dm-inline crypt, though.
- to avoid inclusion of key in DM ioctl calls (mapping table again)
Unless the "trusted" key type is being used it just makes the raw key be
passed to the kernel using a different syscall: add_key() instead of
ioctl(). It doesn't seem fundamentally different.
Technically, yes. Just the key is now sent through ioctl that (should)
be designed for it, not in DM-ioctls that are used extensively for all other
parameters.
We had to add wiping of all buffers there exactly for this reason.
And I think the split is better also for tracing calls etc.
And while all these subsystems are not perfect, they are compatible for many
years. IMO this is very important. We are not in Google monorepo environment
where anything can be changed anytime as you know all users.
Milan
