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) - to avoid inclusion of key in DM ioctl calls (mapping table again) - to somehow simplify keyring handling was used already by other userspace tools (just reference existing keyring instead of creating new one)
- To cause security bugs such as https://lwn.net/Articles/1090568/ . Since otherwise things aren't exciting enough, I guess.
:-) But TBH, this can happen in any other subsystem working with keys. That said, I see keyring as incredibly complex code with complicated CLI tool... Anyway, DM targets should be unified. Userspace support will be tricky, but that is another issue (we have full support for dm-crypt, dm-integrtity maybe requires some API changes. Will check once kernel get the support.) Milan
