On 9/2/2026 5:28 AM, Eric Biggers wrote:
> On Tue, Sep 01, 2026 at 04:22:33PM +0800, Linlin Zhang wrote:
>> 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())
>
> Most I/O requests only need step (2), since they reuse step (1) from a
> previous I/O request. The kernel evicts a keyslot only when it is the
> least recently used among all the keyslots and another one is needed.
> (Or when eviction is explicitly requested.)
>
> This is especially relevant when only a small number of keys is used,
> like is the case when the per-file key support in fscrypt is disabled.
> Programming keys on Qualcomm ICE has always been very slow even on
> physical hardware, and the kernel was already designed to mitigate that.
>
ACK
>> 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.
>
> I think the virtual keyslots are still useful so that the key bytes, key
> size, key type, algorithm, and data unit size don't have to be
> transmitted in every I/O request, then all revalidated and processed
> again. There is a reason that inline encryption hardware uses keyslots,
> and I think the same largely applies to virtio-blk.
>
Thanks for your clarification!
I agree that virtual keyslots still provide an important benefit by
avoiding revalidation of the crypto context on every I/O request and
reducing payload for most encrypted I/O request.
One concern I had is around ownership and lifetime management. If
key programming and I/O submission are exposed through separate interfaces,
the implementation needs to ensure that a programmed virtual keyslot
cannot be modified or replaced unexpectedly before the associated I/O
is submitted. Otherwise, I/O could end up being issued with a different
key than the one originally intended.
As Stefan pointed out, this sounds more like an object lifetime and
permission model problem than a keyslot model problem. My current
thinking is that blk-crypto-proxy could own both virtual keyslot management
and the corresponding access control. For example, key programming and
key eviction could be exposed through blk-crypto-proxy ioctls, while
the block device and its virtual keyslot namespace are instantiated when
the blk-crypto-proxy device is opened. That would allow ownership and
lifetime of programmed keys to be tied to a specific file descriptor context.
Separately, regarding the I/O submission path itself (patch 08 in this
series), I'd also appreciate your thoughts and block maintainers'
opinions on the direction that would be preferable from a block-layer
perspective.
My initial prototype introduced a dedicated ioctl for submitting I/O
carrying blk-crypto metadata because of the additional validation
requirements around DUN handling and data-unit alignment. However, I
understand the concern about introducing a separate I/O submission
interface that bypasses existing optimized paths such as io_uring.
Do you think these blk-crypto-specific requirements should instead be
integrated into an existing interface, such as io_uring, or is there any
precedent for introducing a dedicated interface when additional crypto
metadata needs to accompany I/O requests?
> - Eric
