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

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

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.

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.

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

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.

> 
> (We talked about this in the past, but I am still not familiar enough
> with the Qualcomm hypervisor architecture to understand.)
> 
> Thanks,
> Stefan