Re: [PATCH v1] virtio-blk: Add inline encryption support

[Linlin Zhang <linlin.zhang@oss.qualcomm.com>]

On 8/28/2026 2:49 AM, Eric Biggers wrote:
> On Tue, Aug 25, 2026 at 07:34:09PM -0400, Stefan Hajnoczi wrote:
>> My concern about the key programming interface being a vendor-specific
>> interface beyond the scope of the VIRTIO spec is that I'm not sure if
>> there will ever be any other users. In other words, should ICE actually
>> go into the VIRTIO spec or is it a vendor-specific functionality?
>>
>> The approach with a separate key programming interface seems very
>> specific to UFS and Qualcomm's SCM. For example, is it possible to have
>> multiple virtio-blk devices with their own ICEs (key spaces) or does
>> this design assume there is only one virtio-blk device with ICE per
>> guest because existing SoCs only support that?
>>
>> It would be cleaner and more obvious from a spec perspective if the key
>> programming interface was part of the VIRTIO spec. Then the spec would
>> be self-contained and the vendor-specific part would only be in the
>> device's implementation on the host without also requiring
>> vendor-specific drivers inside the guest.
>>
>> I took a look at the few blk_ll_crypto_ops drivers in the Linux kernel
>> and they are more or less copy-pasted code that only exists because
>> there is no standardized hardware interface. I think we should avoid
>> propagating that into VIRTIO and instead just define a key programming
>> virtqueue for the virtio-blk device once and for all.
>>
>> Having said that, there is much I don't know about ICE, ARM
>> virtualization, etc and I would like to hear your thoughts if you think
>> I'm wrong.
> 
> Looking at the actual Linux kernel patchset that got sent out today
> (https://lore.kernel.org/linux-block/20260827160806.1295313-1-linlin.zhang@oss.qualcomm.com/T/#u),
> I agree with Stefan.  It would be much simpler (and also much more open
> to other implementations) if the key operations were part of the
> virtio-blk protocol, rather than some unspecified out-of-band thing.

Thanks for your comment!

I replied in detail in the Linux kernel patchset thread.

> 
> - Eric