On 9/1/2026 4:41 AM, Stefan Hajnoczi wrote:
> On Fri, Aug 28, 2026 at 11:37:57PM +0800, Linlin Zhang wrote:
>>
>>
>> On 8/28/2026 2:42 AM, Eric Biggers wrote:
>>> On Thu, Aug 27, 2026 at 09:07:09AM -0700, Linlin Zhang wrote:
>>>> From: linlzhan <[email protected]>
>>>>
>>>> Current virtio-blk does not provide a mechanism for a guest to
>>>> program hardware keys or submit encrypted I/O using pre-programmed
>>>> keyslots. It drops the crypto context when issuing a bio request
>>>> to the virtio-blk queue, preventing inline-encryption-based FBE
>>>> on virtio block devices.
>>>>
>>>> This series enables File-Based Encryption in guest VMs on Qualcomm
>>>> GVM platforms where the ICE inline encryption hardware is shared
>>>> between the host and guests. In this environment the guest kernel
>>>> has no access to the ICE hardware directly; it supplies a virtual
>>>> keyslot index and data unit number with each encrypted I/O request
>>>> via VIRTIO_BLK_F_INLINE_ENCRYPTION, and the host must translate the
>>>> virtual slot to a physical ICE keyslot and submit the bio — without
>>>> transferring raw key material across the VM boundary.
>>>
>>> This seems to be designed incorrectly by not making virtio-blk itself
>>> support key programming and eviction. That complicates things
>>> significantly by then having to handle the key programming and eviction
>>> out-of-band using Qualcomm-specific SCM calls. It also means that
>>> adding other implementations of this would be very difficult.
>>>
>>> There are some claims that not transmitting keys across the VM boundary
>>> is desirable. But that doesn't seem meaningful, given that all the I/O
>>> is transmitted across that boundary in plaintext anyway, and also it
>>> seems that hardware-wrapped keys will be supported too.
>>>
>>> Please make virtio-blk support the key programming, eviction, and
>>> HW-wrapped key management operations that are needed for this to work.
>>>
>>> - Eric
>>
>> 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.
>
> Yes, userspace shouldn't have access to the entire physical key slot
> range. The host kernel or other VMs may need key slots and an untrusted
> QEMU process must not be able to modify those key slots or use them for
> I/O.
>
> The uapi design should include a solution for this. For example, there
> could be an ioctl like BLKCRYPTOSEALKEYS that permanently restricts the
> key range on this block device file descriptor and cannot be undone.
> Libvirt or other management tooling would call this ioctl with
> CAP_SYS_ADMIN before passing the file descriptor when launching QEMU
> without CAP_SYS_ADMIN. This prevents QEMU from ever having access to the
> full physical key range.
>
> Just an idea. Those familiar with blk-crypto may have a better one. It
> seems likely that we can find a design that matches the level of
> security of the out-of-band approach.
Thanks for your comment!
Eric mentioned a proposal that each virtio block device has its own *virtual*
keyslots in the host, which is not static partitioning of the physical keyslots.
I have concerns about the new key programing UAPI and 2 VM exits per encrypted
I/O. I'll confirm with Eric if that needs be considered and if we need pass
through the crypto to the host blk-crypto-profile (which means the max slots
of blk-crypto-profile in the guest is 0, and virtio block driver only doesn't
implement the key program interface in blk_crypto_ll_ops).
>
>>
>> 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.
>
> This sounds like an approach that skips key programming and instead
> sends the keys along with each I/O request. The device implementation is
> responsible for managing key slots on the physical ICE. My main concern
> with this would be whether the blk_crypto_ll_ops semantics can be
> faithfully replicated (e.g. error reporting) without explicit key
> programming operations.
>
> Stefan
You're right. When the virtio-blk device processes encrypted I/O, it
would be responsible for extracting the blk_crypto_key and DUN from the
virtqueue and attaching them to the bio (via bio_crypt_set_ctx()). The
existing keyslot management logic in the block layer would then handle
physical keyslot allocation and waiting as needed, so the rest of the
blk-crypto infrastructure should continue to work unchanged.
Regarding your concern, there is already a somewhat similar
implementation in the device-mapper layer (
dm_table_construct_crypto_profile() implements a passthrough
blk_crypto_ll_ops profile. See
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/md/dm-table.c?h=v7.3-rc1
).
Based on my current understanding, I don't see any obvious
architectural issues with this approach. However, I may be missing
something, so I'd appreciate any feedback if you see flaws in the
design or potential problems that should be taken into account.
>
>>
>> - 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.
>>
>> Regards,
>> Linlin
>>
>>
>>
