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

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.

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

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

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

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.

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
>