On 9/2/2026 3:44 AM, Stefan Hajnoczi wrote:
> On Tue, Sep 01, 2026 at 04:45:19PM +0800, Linlin Zhang wrote:
>>
>>
>> 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.
>
> If the virtual key slots in the uapi are per file descriptor rather than
> per inode, then other programs cannot interfere with each other's
> virtual key slots. Each program gets its own virtual key space when it
> opens a file descriptor. Sharing is only possible by inheriting or
> passing a file descriptor to another process and that's good for
> security.
>
Thanks for your advice!
That sounds a good way. I'll check if this mechanism can be used in the above
design properly.
> Stefan
