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

--iTqlhHCyo41V/Nv2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 04, 2026 at 09:57:11PM +0800, Linlin Zhang wrote:
> On 2/3/2026 10:43 PM, Stefan Hajnoczi wrote:
> > On Tue, Feb 03, 2026 at 06:06:33PM +0800, Linlin Zhang wrote:
> >> On 2/2/2026 11:56 PM, Stefan Hajnoczi wrote:
> >>> On Fri, Jan 30, 2026 at 06:23:55PM +0800, Linlin Zhang wrote:
> >>>> On 1/28/2026 5:09 AM, Stefan Hajnoczi wrote:
> >>>>> On Tue, Jan 27, 2026 at 10:20:32PM +0800, Linlin Zhang wrote:
> >>>>>> +  starting block of the request.
> >>>>>> +\end{itemize}
> >>>>>> +
> >>>>>>  VIRTIO_BLK_T_IN requests populate \field{data} with the contents =
of sectors
> >>>>>>  read from the block device (in multiples of 512 bytes).  VIRTIO_B=
LK_T_OUT
> >>>>>>  requests write the contents of \field{data} to the block device (=
in multiples
> >>>>>> @@ -912,6 +979,8 @@ \subsection{Device Operation}\label{sec:Device=
 Types / Block Device / Device Ope
> >>>>>>  successfully, failed, or were processed by the device at all if t=
he request
> >>>>>>  failed with VIRTIO_BLK_S_IOERR.
> >>>>>> =20
> >>>>>> +A driver MUST set \field{activate} to 0 for a non VIRTIO_BLK_F_IC=
E request.
> >>>>>
> >>>>> Please explicitly list request types where the payload field is pre=
sent
> >>>>> and where activate is optional.
> >>>>
> >>>> How about adding the following supplement?
> >>>>
> >>>>   \begin{itemize}
> >>>>   \item only when the block request contains crypto context and the =
request type
> >>>
> >>> I'm not sure what "when the block request contains crypto context"
> >>> means. Is that the same as "when VIRTIO_BLK_F_ICE has been negotiated=
"?
> >>
> >> No, crypto context means bio_crypt_ctx in BIO struct.
> >>   struct bio {
> >>   ...
> >>   #ifdef CONFIG_BLK_INLINE_ENCRYPTION
> >> 	  struct bio_crypt_ctx	*bi_crypt_context;
> >>   #endif
> >>   ...
> >>   }
> >>
> >> When VIRTIO_BLK_F_ICE has been negotiated, virtio block backend receiv=
es crypto
> >> payload from virtio block frontend, and the crypto payload, together w=
ith I/O
> >> transaction, is sent to block layer of the host finally. The crypto pa=
yload is
> >> used to construct the bio_crypt_ctx filed of BIO.
> >=20
> > Is that equivalent to struct virtio_blk_crypto_payload in this patch? If
> > yes, then I suggest only talking about the payload or slots - concepts
> > that are part of the virtio-blk inline crypto interface - instead of
> > Linux's bio_crypt_ctx.
> >=20
> > If that's not possible, then the crypto context needs to be defined in
> > the spec so that readers know what it means.
>=20
> Crypto context - bio_crypt_ctx structure - is different with virtio_blk_c=
rypto_payload.
> bio_crypt_ctx is the struct bound to BIO and request structs in Linux to =
imply this is
> a inline encryption bio/request. While virtio_blk_crypto_payload is a new=
 struct in this
> patch, it is used to issue the inline encryption metadata (slot, activate=
, DUN) to the
> virtio backend, so that the backend virtio device can use such inline enc=
ryption metadata
> to initialized the crypto info of Storage protocol. For instance, the CCI=
 in DW0 of UTP
> Transfer Request Descriptor.
>=20
> Change it to the following.
>   \begin{itemize}
>   \item only when the block request contains a valid bio_crypt_ctx and th=
e request type
>   is one of VIRTIO_BLK_T_IN, VIRTIO_BLK_T_OUT and VIRTIO_BLK_T_FLUSH,\fie=
ld{activate} MUST
>   be set to 1. bio_crypt_ctx is defined in linux/blk-crypto.h.
>     \begin{lstlisting}
>     struct bio_crypt_ctx {
>         const struct blk_crypto_key     *bc_key;
>         u64                             bc_dun[BLK_CRYPTO_DUN_ARRAY_SIZE];
>     };
>     \end{lstlisting}

bio_crypt_ctx is Linux-specific. Can you phrase this in a way that does
not rely on Linux block layer concepts?

For example:

  The \field{activate} field is set to 1 on VIRTIO_BLK_T_IN,
  VIRTIO_BLK_T_OUT, and VIRTIO_BLK_T_FLUSH requests that require inline
  encryption. For other request types or when inline encryption is not
  required, it is set to 0.

Thanks,
Stefan

--iTqlhHCyo41V/Nv2
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmmDgZUACgkQnKSrs4Gr
c8hrrwgAxk6twn/r30jNrLVg7ma5ZFK2Y6AkFbLySPrq8ArAfTBGANfLkc3EKu52
O5XQpAotbU+w1QKwbhEX9/yacLswP2cRFmzDg0r3ncHNCqdPjQCi8P0YGW3ZtTu6
nm3WHNxps35Sih40SOS1DVt/K6f7jHJCvWgOEG2Kzh9BJ3F3Lin5jpSNdwWcCybh
zCx7UFKlQyyCfuyyMSxBQY4fPb+caB5ThoGFgvoDBCDRqZHduufLDMT6YGsVtmkx
Ot3JwNJJMQdjZNqtxQm9aGWz5j5YGVkkHFK7F++O1Z6yEvSpL973fmbBTNbiVvz1
FBYcw0FswrSybLZfK+Bsk2VIKpOH3g==
=2mn1
-----END PGP SIGNATURE-----

--iTqlhHCyo41V/Nv2--