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

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

On 8/26/2026 7:34 AM, Stefan Hajnoczi wrote:
> On Thu, Aug 20, 2026 at 10:37:47PM +0800, Linlin Zhang wrote:
>>
>>
>> On 8/20/2026 3:35 AM, Stefan Hajnoczi wrote:
>>> On Wed, Aug 19, 2026 at 07:30:15PM +0800, Linlin Zhang wrote:
>>>>
>>>>
>>>> On 8/19/2026 12:33 PM, Eric Biggers wrote:
>>>>> On Fri, Aug 14, 2026 at 07:23:01AM -0700, Linlin Zhang wrote:
>>>>>> When the feature is negotiated, the device reports inline encryption
>>>>>> characteristics through virtio_blk_enc_characteristics. Add
>>>>>> VIRTIO_BLK_T_GET_CRYPTO_MODES, VIRTIO_BLK_T_CRYPTO_IN, and
>>>>>> VIRTIO_BLK_T_CRYPTO_OUT so that the driver can discover supported
>>>>>> crypto modes and submit inline-encrypted I/O requests.
>>>>>
>>>>> How is the driver expected to program and evict keyslots?
>>>>
>>>> There are 2 new added drivers, one is virtio blk extension driver which is
>>>> generic, and the other is crypto virtualization driver which is vendor
>>>> specific.
>>>>
>>>> The virtio blk extension driver manages the initialization of blk-crypto-profile,
>>>> and implements the interfaces of blk_crypto_ll_ops.
>>>>
>>>> The crypto virtualization driver performs similar operation like the key handling
>>>> part in ufs-qcom and ice drivers. It forwards the key program/eviction request to
>>>> Trust Zone via SMC call.
>>>>
>>>> For QCOM, the whole flow of key program/eviction is like
>>>>   - block layer passes the request to virtio_blk extension driver via blk_crypto_ll_ops
>>>>   - virtio_blk extension -> crypto virtualization -> qcom_scm -> SCM -> HYP ->TZ
>>>
>>> Can you annotate this with "guest" and "host"? Here is my guess:
>>> - virtio_blk + extension driver: guest
>>> - crypto virtualization + qcom_scm + SCM: guest
>>> - HYP: host
>>> - TZ: host
>>>
>>> If this is correct, then it's unclear to me why a vendor-specific guest
>>> component is involved?
>>
>> Thanks for your comments!
>>
>> That 's correct basically.
>>
>> - Guest VM
>> - virtio-blk + virtio-blk crypto extension
>> - crypto virtualization driver + qcom_scm
>> - SCM interface
>>
>> - Secure World/Platform
>> - Hypervisor
>> - Trust Zone
>>
>> The primary purpose of introducing a vendor-specific guest component is to
>> enable the guest VM to handle key programming and eviction directly through
>> TrustZone, avoiding any dependency on the primary VM for these operations.
> 
> If I understand correctly, you are saying that the qcom_scm driver
> inside the guest (EL1) uses the SMC instruction to trap directly into
> the host's Secure World (EL3) without going through the hypervisor
> (EL2)?
> 

There are 2 kinds of hypervisors. Sorry that I only focused on the type-1
hypervisor previously.

For type-1 hypervisor, qcom_scm driver inside the guest (EL1) uses the
SMC instruction to trap into the hypervisor (EL2) first, and the hypervisor
transfers SMC call to the Secure World (EL3), totally bypass the primary VM.

For type-2 hypervisor, qcom_scm driver inside the guest (EL1) goes to the
host via HAB driver (which is in upstream progress), the host (EL2)
transfers SMC call to the Secure World (EL3).

> If the virtio-blk interface standardized blk_crypto_ll_ops requests,
> then virtqueue requests would instead be used instead of SMC
> instructions and the hypervisor's (EL2) device emulation would handle
> the key programming on behalf of the guest.
> 

Thanks for the point!

The hypervisor's (EL2) device emulation you mean is QEMU, right? 
I said QEMU in the following as the hypervisor's (EL2) device emulation.

If I understand correctly, the key programming flow you suggested is like
the following.

  GVM -> blk_crypto_ll_ops in virtio-blk
      -> virtqueue request
      -> the hypervisor's (EL2) device emulation (QEMU)
      -> key programming in Host module
      -> ICE

To support it, 
  1. need create a new control queue for the transmission of blk_crypto_ll_ops
     requests
  2. in the program key interface of blk_crypto_ll_ops, it has the key
     and the slot index the key provisioned to, Guest VM only knows the
     virtual slots, so the virt_slot need be transferred to the corresponding
     physical one in QEMU or the following flow before programming it to ICE
  3. QEMU is a userspace process, we need add new blk ioctls (like key
     generate/import/prepare ioctls added recently) to allow the
     userpsace client to program a key to ICE

The 3rd point is my main concern, if such ioctls (program/evict/derive_sw_secret)
can be added, especially that the program key ioctl which specifies the key to the exact
slot, and the evict key ioctl which allows the usespace client wipe the key
in a specific slot. I thought it's a high security concern.

Another concern is the broken of key isolation b/w VMs, except more VM exit
operations.

>> Because SCM firmware interfaces can differ across vendors, the design
>> introduces an intermediate crypto virtualization layer. This layer provides
>> a common abstraction for key management operations, while allowing each
>> vendor to implement the backend interfaces according to its specific SCM
>> firmware and security architecture.
> 
> Which layer is the "intermediate crypto virtualization layer" that you
> are describing? I don't see that in this spec proposal. Is it the
> existing blk_crypto_ll_ops struct in Linux?
> 

I mean the 'crypto virtualization driver', which is corresponding to the
crypto_virt.c in the kernel patch series.

See https://lore.kernel.org/all/20260827160806.1295313-3-linlin.zhang@oss.qualcomm.com/

>>> What is the advantage of shipping qcom_scm inside the guest versus
>>> defining a standard virtio-blk interface for blk_crypto_ll_ops that the
>>> hypervisor's virtio-blk device implements via TZ on the host?
>>
>> Keeping SCM in the guest preserves key isolation, minimizes virtio-blk
>> payloads, and avoids additional inter-VM communication.
>>
>> Key programming occurs after a request has entered the block request
>> queue. Performing it through a standard virtio-blk request would require
>> issuing key request in the same request before handling I/O path,
>> introducing dead lock concerns.
> 
> A separate key programming virtqueue can be used to avoid deadlock
> concerns. That way is is still possible to access the key programming
> interface when a request queue is full.
> 

Thanks.
I agree with you. A separate control virtqueue must be added for the
virtio-blk interface standardized blk_crypto_ll_ops requests.

>> In my opinion, passing the encryption key in each virtio-blk request is
>> also undesirable, as it exposes key material outside the guest, increases
>> request size, and adds VM transition overhead.
> 
> I'm not sure there is a significant security benefit since the device
> emulation code in the hypervisor already has access to the plaintext I/O
> buffers, can snoop guest memory, and can cause guest code execution
> (including accessing the qcom_scm driver inside the guest)?
> > Regarding the VM transition overhead, I think you are right unless blk
> crypto changes are made to allow a more efficient request submission
> scheme (like combining key programming with I/O requests if there is a
> bottleneck in the I/O path). However, it's not clear to me whether key
> programming is a performance bottleneck: hopefully key programming does
> not happen in the I/O path and only in the control path when opening a
> file or directory?
> 

Thanks for the clarification.

From the memory visibility perspective, I agree with you that the guest
keys are transparent for the host. From the key's ownership aspect, I
feel that the host programming the key on behalf of the guest leads to
the ownership change, I'm not sure if it's a security concern.

The key programming occurs when submitting BIO to the request in the I/O
path, which means pre read/write from the virito device triggers programing
key first(vm exit -> QEMU -> the host program key module -> TZ -> ICE ->
back to the guest), and then send IO request(vm exit -> QEMU -> the host
I/O path). Compared with the SMC call from GVM solution (implemented in
https://lore.kernel.org/linux-block/20260827160806.1295313-1-linlin.zhang@oss.qualcomm.com/T/#u),
the key programming via virtio involves one 1 more vm exit.

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

I have confidence that this is a generic requirement for the virtualization
platform. It's better to have it in the virtio SPEC.
And there is a new common virtio block ops added for the key programming.
This allows the vendor to implement the key program based on their platform.

See https://lore.kernel.org/all/20260827160806.1295313-3-linlin.zhang@oss.qualcomm.com/,
the vendor need implement the virtblk_crypto_variant_ops in 
https://lore.kernel.org/all/20260827160806.1295313-2-linlin.zhang@oss.qualcomm.com/#Z31include:linux:virtio_blk_crypto_ext.h

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

Yes. This design does allow multiple virtio-blk devices with inline
encryption supported. And per virtio-blk device has its own ICE. Though
only one ICE is assumed in above Linux patch set, a small change can
be made to support different virtio-blk devices with different ICEs,
and don't need update the virtio SPEC.

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

I agree with you that programming interfaces in virtio SPEC makes it more
clear for the one who implements it. Current design is a compromise of
the security concern and the virtio protocol. Implementing it need a
full understanding of the inline encryption feature bit in virtio SPEC
and the virtio blk code in the Linux kernel.(See the above link of
virtio_blk_crypto_ext.h)

Would you please go through the virtio blk inline encryption support
patch (https://lore.kernel.org/all/20260827160806.1295313-3-linlin.zhang@oss.qualcomm.com/)
and double confirm if this combination (virtio spec defines the data
flow for crypto IO, virtio_blk_crypto_ext defines the control flow
of crypto IO) can be accepted?

I'm appreciated your insights.

> 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.
> 
> Thanks,
> Stefan
> 
>>
>>>
>>> (We talked about this in the past, but I am still not familiar enough
>>> with the Qualcomm hypervisor architecture to understand.)
>>>
>>> Thanks,
>>> Stefan
>>