Re: [PATCH v1] virtio-blk: Add inline encryption support

Stefan Hajnoczi <[email protected]>
Newsgroups dev.linux.lists.virtio-dev
Message-ID <20260819193555.GA470114@fedora>
On Wed, Aug 19, 2026 at 07:30:15PM +0800, Linlin Zhang wrote:
> 
> 
> On 8/19/2026 12:33 PM, Eric Biggers wrote:
> > On Fri, Aug 14, 2026 at 07:23:01AM -0700, Linlin Zhang wrote:
> >> When the feature is negotiated, the device reports inline encryption
> >> characteristics through virtio_blk_enc_characteristics. Add
> >> VIRTIO_BLK_T_GET_CRYPTO_MODES, VIRTIO_BLK_T_CRYPTO_IN, and
> >> VIRTIO_BLK_T_CRYPTO_OUT so that the driver can discover supported
> >> crypto modes and submit inline-encrypted I/O requests.
> > 
> > How is the driver expected to program and evict keyslots?
> 
> There are 2 new added drivers, one is virtio blk extension driver which is
> generic, and the other is crypto virtualization driver which is vendor
> specific.
> 
> The virtio blk extension driver manages the initialization of blk-crypto-profile,
> and implements the interfaces of blk_crypto_ll_ops.
> 
> The crypto virtualization driver performs similar operation like the key handling
> part in ufs-qcom and ice drivers. It forwards the key program/eviction request to
> Trust Zone via SMC call.
> 
> For QCOM, the whole flow of key program/eviction is like
>   - block layer passes the request to virtio_blk extension driver via blk_crypto_ll_ops
>   - virtio_blk extension -> crypto virtualization -> qcom_scm -> SCM -> HYP ->TZ

Can you annotate this with "guest" and "host"? Here is my guess:
- virtio_blk + extension driver: guest
- crypto virtualization + qcom_scm + SCM: guest
- HYP: host
- TZ: host

If this is correct, then it's unclear to me why a vendor-specific guest
component is involved?

What is the advantage of shipping qcom_scm inside the guest versus
defining a standard virtio-blk interface for blk_crypto_ll_ops that the
hypervisor's virtio-blk device implements via TZ on the host?

(We talked about this in the past, but I am still not familiar enough
with the Qualcomm hypervisor architecture to understand.)

Thanks,
Stefan
signature.asc (application/pgp-signature, 488 B)
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmqGBZsACgkQnKSrs4Gr
c8in/wf+I4fXSV2EaNp08gyugaqzan2sNnB+Nsl7vq40fzaUqvYCare8m8Cz/WLs
x+A6CS4DXNjUPE42UZvuCVtzMe1bb5S0yl+Q7J3qb3X6YplZkVSiNB4zKAmGmRdI
IanccMxYJVtEiSeGSEDiGSHwUJ8UTdOQ2lKfs48NVKs0e66bua/SFEez9GPErzfZ
6uLG38KiTTzCertlf2fnBS6Vc4KTN9EalYx0x6w+RW3Zx8ZnCkyBJjmogEvDFFu+
3O6NXBFkJtENCiE63pQ9bd8YiUr3lqQ9vFLAphSa23M4boARICZL0brW82C8owc8
ItsNRhYLPi98eV4+C7lsmujphTVhWw==
=60/4
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.