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

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 8898 bytes --]

On Tue, Sep 01, 2026 at 05:21:53PM +0800, Linlin Zhang wrote:
> 
> 
> 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 <linlin.zhang@oss.qualcomm.com>
> >>>>
> >>>> 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.

I don't have enough blk-crypto knowledge to give good feedback on the
details of this approach, but Eric and others could help with that.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]