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
