On Mon, 5 May 2025, Eric Biggers wrote: > On Mon, May 05, 2025 at 06:15:01PM +0200, Mikulas Patocka wrote: > > > > I have a dumb question - if it doesn't matter through which block device > > do you set up the keys, why do you set them up through a block device at > > all? > > > > What about making functions that set up the keys without taking block > > device as an argument, calling these functions directly and bypassing > > device mapper entirely? > > Userspace needs to direct the key setup operations, so we'd need a UAPI for it > to do so. We could add a custom syscall, or some hacked-up extension of > add_key(), and add a custom registration mechanism to allow a single > implementation of wrapped keys (e.g. from ufs-qcom) to register itself as the What happens if there are multiple ufs-qcom controllers? Is it unsupported? > system's wrapped key provider which the syscall would then use. > > But it seemed cleaner to instead use block device ioctls and take advantage of > the existing blk-crypto-profile. That already handles registering and > unregistering the implementation, and it also already handles things like > locking, and resuming the UFS controller if it's in suspend. > > It also keeps the door open to supporting the case where different > wrapped-key-capable block devices don't necessarily accept the same keys, even > if that isn't the case currently. > > - Eric I think that using ioctl on block device is ok. But I don't see why do you need to perform the ioctl on device mapper device and let device mapper select a random underlying device where the ioctl is forwarded? You can as well select a random physical disk in your userspace application and call the ioctl on it. Mikulas
