On Fri, Aug 28, 2026 at 09:08:26PM +0800, Linlin Zhang wrote:
> 
> 
> 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).

I see. The VM exit performance advantage with SCM does not seem to be
that great since EL2 is involved in both cases, just that the primary VM
can be bypassed in the Type 1 case.

Technically it ought to be possible to bypass the Type 1 primary VM even
with a virtqueue (similar to how vhost devices in the Linux kernel can
offload virtqueues from QEMU userspace to the host kernel), but that
involves extra work and complexity - it's only worth it key programming
this is performance bottleneck.

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

Security could be improved by limiting QEMU's key slot index range to
the virtual slots assigned to the guest. That way QEMU has no more
privileges than the guest and the impact of a VM escape is reduced.

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

Yes, I think it would be necessary to limit userspace's physical key
slot access. The driver interface (e.g. ioctl) should be designed to
restrict the key slot index range.

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

Thanks, I will take a look.

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

Can you clarify what you mean by "1 more vm exit", that wording is
confusing to me since an SMC guest instruction also causes a 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

These are Linux kernel patches, not VIRTIO spec definitions. The VIRTIO
spec is independent of the Linux kernel source code (except where
explicitly designed to pass through Linux structures). There needs to be
information in the VIRTIO spec about the key programming interface
concepts so that someone implementing a driver or device knows how key
slots behave even if the actual programming interface (e.g. Qualcomm's
SCM interface) details are not covered by the spec.

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

Sure, I will take a look at the Linux patches.

Stefan

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