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
