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
