Re: [PATCH v1 00/11] FBE virtualization: inline encryption for virtio-blk guests

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

On 9/1/2026 4:22 PM, Linlin Zhang wrote:
> 
> 
> On 9/1/2026 5:07 AM, Eric Biggers wrote:
>> On Fri, Aug 28, 2026 at 11:37:57PM +0800, Linlin Zhang wrote:
>>> Thanks for your comments!
>>>
>>> Not making virtio-blk itself support key programming and eviction is
>>> something done deliberately. Based on that HW-wrapped key management
>>> operations are also handled in the out-of-band path.
>>>
>>> There are bellow 2 approaches I investigated to let virtio-blk programming
>>> the key.
>>>
>>>   1. virtio_blk implements blk_crypto_ll_ops interfaces, including program
>>>      key and evict key interfaces.(Same to 'the virtio-blk interface standardized
>>>      blk_crypto_ll_ops requests' mentioned by Stefan in the virtio SPEC thread)
>>>
>>>      The guest's block crypto profile manages the keyslot in virtual slot
>>>      format in this scenario.
>>>
>>>       - block crypto key and virt_slot index it passed to the hypervisor's
>>>        (EL2) device emulation (QEMU, using QEMU in the following) which
>>>        runs in userspace of the host. Besides of transferring the virtual
>>>        slot to the physical slot, a programming block crypto key UAPI need
>>>        be added. Follow current blk-crypto design, it may be like
>>>        BLKCRYPTOGENERATEKEY. I thought this results in a security risk that
>>>        allows userspace process a key into a key slot.
>>>
>>>      - For key eviction, it's similar to above key programming handling, also
>>>        need a key eviction in blk IOCTLs, but leads to the security risk
>>>        that allow userspace client to evict a key in a key slot.
>>>
>>>     virt_slot, DUN and DUSize is appended to virtblk request during crypto
>>>     I/O.
>>>
>>>   2. virtio_blk implements blk_crypto_ll_ops interfaces, excluding program
>>>      key and evict key interfaces.
>>>
>>>      The guest's block crypto profile doesn't manage keyslot for the guest,
>>>      the host's block crypto profile manages keyslot for both the guest and
>>>      the host. The trigger of key programming operation is moved from the
>>>      guest to the host.
>>>
>>>        - The whole block crypto key (key size, key bytes, blk_crypto_config)
>>>          and DUN are appended to the virtblk request during IO, a little
>>>          high payload.
>>>
>>>          The backend parses the crypto message in the virtio queue and
>>>          construct a block crypto key and DUN for the bio_crypto_ctx
>>>          set to the BIO. So that the IO flow in the host can program
>>>          the key. 
>>>
>>>          The question is that the blk-crypto-profile distinguishs the
>>>          block crypto key via the key's address. But the host has
>>>          different key addresses for the programming and eviction key
>>>          operations of the same block crypto key from GVM, because the
>>>          key is re-constructed in the host for the key program and
>>>          eviction operations. 
>>>
>>>          To fix it, the approach I thought is maintaining a new key
>>>          hash table in the backend, and comparing the block crypto key
>>>          content and DUN parsed from virtio queue with that in the key
>>>          hash table. 
>>>          My major concern is that this need keep the keys synchronization
>>>          b/w this new hash table and the blk-crypto-profile's hash table
>>>          carefully, avoiding that key is still present in the
>>>          blk-crypto-profile's hash table, but removed in backend hash
>>>          table. Another point is that the whole block crypto key and
>>>          DUN are appended into virtio block request per crypto I/O.
>>>
>>>        - For key eviction, adding a key eviction in blk IOCTLs allows
>>>          userspace client to evict a key in a key slot. I thought this
>>>          is a security concern.
>>>
>>>
>>>      This option doesn't need map virt_slot to physical one.
>>>
>>>
>>> Taking all the above into account, I made a compromise to implement
>>> blk_crypto_ll_ops interfaces in a out-of-band path, which lets the virtio
>>> blk only need focus on the data path. I agree that it is complex than
>>> the second option mentioned in the above, but small payload (only
>>> virt_slot, DUN, DUSize) in the virtio block request and no security
>>> risk of key eviction from userspace.
>>>
>>>
>>> I would like to hear your thoughts about the above and am appreciated
>>> if you could share your insights about the design of inline
>>> encryption in virtio block.
>>
>> Well, the way it should work is that each virtio-blk device should have
>> its own set of *virtual* keyslots on the host side.  From the guest's
>> perspective it would act very similarly to UFS / eMMC inline encryption,
>> and it would be easy to integrate into the existing stack.
>>
>> Then to process encrypted I/O, the host would use the keyslot number in
>> the I/O to look up the blk_crypto_key it previously saved, and issue I/O
>> using that key (using bio_crypt_set_ctx()).  The existing keyslot
>> management logic in the block layer would allocate or wait for a
>> physical keyslot as needed, so it should just work.
>>
>> Eviction would similarly be passed through to blk_crypto_evict_key().
>>
>> Note that with this design, there would be no static partitioning of the
>> physical keyslots.  The host would just allocate and release them as
>> needed, similar to memory allocation.  The total number of virtual
>> keyslots could be greater than the number of physical keyslots.
>>
>> This design would also work with hardware-wrapped keys.
>>
>> The hardest part is still the UAPIs for the VMM to do what it needs to
>> do (assuming that it even needs to support physical inline encryption
>> hardware at all, and not simply use the AES acceleration on the CPU),
>> but that is the case with any of the proposals.
>>
>> - Eric
> 
> Thanks for your insights and clarification.
> 
> This is a very clear architecture for virtio-blk inline encryption support
> and is quite similar to what I referred to as approach 1, with a few notable
> differences:
> 
>   - The host maintains a set of virtual keyslots per virtio-blk device.
>   - Physical keyslots are not statically partitioned.
>   - The virtual-to-physical slot mapping is managed as part of the virtio-blk
>     device implementation rather than being tied to a VM-wide slot table.
> 
> With this design, I believe there would be two VM exits associated with
> encrypted I/O:
>   1. Key programming
>      Before encrypted I/O can be submitted, the guest needs to program a key
>      into a virtual keyslot:
>      
>      Guest virtio-blk driver
>          -> VM exit
>          -> virtio-blk backend (e.g. QEMU)
>          -> ioctl
>          -> host virtio-blk proxy driver
>             (stores the blk_crypto_key in a virtual keyslot)
> 
>   2. Encrypted I/O submission
>      The I/O request carries the virtual keyslot number and DUN:
> 
>      Guest virtio-blk driver
>         -> VM exit
>         -> virtio-blk backend (e.g. QEMU)
>         -> ioctl
>         -> host virtio-blk proxy driver
>            (looks up the blk_crypto_key associated with the virtual keyslot
>             and submits I/O using bio_crypt_set_ctx())

Supplementation.
This may be a potential security concern. The host virtio-blk proxy driver exposes
API for key programming, the input parameters are blk_crypto key and virtual
slot. If a malicious program replace the key in a specific virtual slot between
key program call and I/O submission via this API, the data would be encrypted
by the unintentional key.

> 
> I have been wondering whether a model similar to the passthrough
> blk-crypto-profile used by certain dm targets could be applicable here.
> 
> In such a design, ownership of keyslot management would effectively and totally
> move to the host. The guest would no longer manage virtual keyslots, and the
> host block layer would continue using its existing keyslot manager to allocate,
> reuse, and evict physical keyslots as needed.
> 
> This corresponds to what I previously described as approach 2.
> With this approach, encrypted I/O would require only a single VM exit:
>   1. Encrypted I/O submission
>      The I/O request carries the blk_crypto_key and DUN:
> 
>      Guest virtio-blk driver
>         -> VM exit
>         -> virtio-blk backend (e.g. QEMU)
>         -> ioctl
>         -> host virtio-blk proxy driver
>            (receives the blk_crypto_key and DUN, then submits I/O using
>             bio_crypt_set_ctx())
> 
> Regardless of which approach is used, the host would still need to maintain a
> key lookup table so that the host blk-crypto layer consistently sees the same
> blk_crypto_key object for a guest key until that key is evicted.
> 
> Note that, the key table format is
>   - approach 1: <virtual_slot, blk_crypto_key>
>   - approach 2: <hash_id of blk_crypto_key, blk_crypto_key>
> 
> Therefore, if transferring blk_crypto_key material from the guest to the host
> (and from userspace to kernel space) is considered acceptable, I wonder whether
> approach 2 might be preferable because it avoids virtual keyslots entirely and
> reduces the encrypted I/O path to a single VM exit.
> 
> Do you see any major drawbacks with such an approach? In particular, do you
> think reducing the number of VM exits by eliminating virtual keyslots is a
> worthwhile direction for virtio-blk inline encryption support?
> 
> - Linlin