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

[Eric Biggers]

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.

> 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.

- Eric