Re: [PATCH v6 4/4] virtio-blk: Add inline encryption security considerations

["Michael S. Tsirkin" <mst@redhat.com>]

Good start! Yet something to improve:

On Tue, Oct 27, 2026 at 02:09:27AM -0700, Linlin Zhang wrote:
> Inline encryption protects the data stored on the backend storage, but
> the device, and therefore the host, is able to read the buffers of both
> the request virtqueues and the administration virtqueue.
> 
> Describe the resulting exposure. The data of the requests is transferred
> in plaintext, so inline encryption is not a means of keeping data
> confidential from the host, whichever key type is used, and confidential
> guests cannot rely on it for that.
> 
> A raw key programmed into a keyslot is visible to the host. A
> hardware-wrapped key prevents the raw key from being extracted, so that
> the key can only be used through the device which wrapped it, but does
> not prevent the host, which is able to send administration commands
> itself, from using the key through the device.
> The raw key imported by VIRTIO_BLK_ADMIN_CMD_CRYPTO_IMPORT_KEY and the
> software secret returned by VIRTIO_BLK_ADMIN_CMD_CRYPTO_DERIVE_SW_SECRET
> are also visible to the host.
> 
> This patch adds no normative requirements.
> 
> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/238
> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>


This needs to be rewritten:
- use terminology from spec (or standards linked to) do not make up your
  own
- address physical device implementations and software ones
- specific recommendations lacking

> ---
>  device-types/blk/description.tex | 40 ++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/device-types/blk/description.tex b/device-types/blk/description.tex
> index bbae9af..ca54e50 100644
> --- a/device-types/blk/description.tex
> +++ b/device-types/blk/description.tex
> @@ -1994,6 +1994,46 @@ \subsubsection{Inline Encryption Administration Commands}\label{sec:Device Types
>  NOT write key material or the derived software secret to the
>  \field{command_specific_result}.
>  
> +\subsubsection{Inline Encryption Security Considerations}\label{sec:Device Types / Block Device / Device Operation / Inline Encryption Security Considerations}
> +
> +Inline encryption protects the data stored on the backend storage, for
> +example against an attacker who obtains the storage medium on its own. It
> +is not a means of keeping data confidential from the host: the device, and
> +therefore the host, is able to read the buffers of both the request
> +virtqueues and the administration virtqueue. A confidential guest, for
> +example a guest whose memory is protected from the host by a confidential
> +computing technology, cannot rely on inline encryption to keep its data
> +confidential from the host, whichever key type it uses.


Pls reword in terms of device/driver, not host/guest.
"confidential guest" is also not a common term

E.g. "an untrusted device", "a driver that does not trust the device".
You can give examples "e.g. as is common with
confidential computing configurations".

this applies everywhere.

> +
> +\begin{note}
> +Inline encryption does not protect the data of VIRTIO_BLK_T_CRYPTO_OUT and
> +VIRTIO_BLK_T_CRYPTO_IN requests from the host: that data is transferred in
> +plaintext in buffers of the request virtqueues.
> +\end{note}
> +
> +When \field{key_type} is VIRTIO_BLK_CRYPTO_KEY_TYPE_RAW, the key material in
> +the \field{bytes} of struct virtio_blk_crypto_key_desc of a
> +VIRTIO_BLK_ADMIN_CMD_CRYPTO_KEYSLOT_PROGRAM command is the plaintext key.

the plaintext key?

> +Any software able to access the buffers of the administration virtqueue,
> +such as the hypervisor, the device implementation or other software on the
> +host, can therefore obtain the key, and decrypt the data encrypted with it
> +at any time, including after the key is no longer in use.

what does it have to do with software, unclear.

> +
> +When \field{key_type} is VIRTIO_BLK_CRYPTO_KEY_TYPE_HW_WRAPPED, a
> +VIRTIO_BLK_ADMIN_CMD_CRYPTO_KEYSLOT_PROGRAM command only transfers a key
> +wrapped by the device, and the raw key material is not exposed in its
> +buffers.

material?

the considerations are same or different for different key types?
pls structures the text to make it clear what applies to what.


> This prevents the raw key from being extracted, so that the key
> +can only be used through the device which wrapped it. It does not prevent
> +the host, which is able to send administration commands itself, from using
> +the key through the device, for example by converting a long-term wrapped
> +key it has observed with VIRTIO_BLK_ADMIN_CMD_CRYPTO_PREPARE_KEY and
> +programming the result into a keyslot. Moreover, a
> +VIRTIO_BLK_ADMIN_CMD_CRYPTO_IMPORT_KEY command carries the raw key in its
> +\field{command_specific_data}, and the struct virtio_blk_crypto_sw_secret
> +returned by a VIRTIO_BLK_ADMIN_CMD_CRYPTO_DERIVE_SW_SECRET command is
> +visible in its \field{command_specific_result}, so these commands expose
> +secrets to the host in the same way as raw keys.


this seems to argue with itself about some kind of protection
that maybe could be there but is not?


> +
>  \subsubsection{Legacy Interface: Device Operation}\label{sec:Device Types / Block Device / Device Operation / Legacy Interface: Device Operation}
>  When using the legacy interface, transitional devices and drivers
>  MUST format the fields in struct virtio_blk_req
> -- 
> 2.34.1