Re: [PATCH v2 2/2] dm: pass through operations on wrapped inline crypto keys

[Eric Biggers <ebiggers@kernel.org>]

On Mon, May 05, 2025 at 11:01:38PM +0200, Mikulas Patocka wrote:
> 
> 
> 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?

They would accept the same wrapped keys, I think.  But that is theoretical,
since multiple ufs-qcom hosts are currently unsupported for other reasons.

> > 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.

We have to forward derive_sw_secret anyway, since that's invoked by the
filesystem, not by the ioctls.

The other operations are for the ioctls, but I don't see a reason to make things
harder for userspace by forcing userspace to implement logic like:

    if (is_dm(blkdev))
        blkdev = underlying_device(blkdev)
    ioctl(blkdev)

The device-mapper block device has a blk-crypto profile that declares wrapped
key support.  We should just make the ioctls work on that block device, so that
upper layers don't need to care whether it's device-mapper or native.

- Eric