Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
Cc: virtio-dev@lists.linux.dev, ebiggers@kernel.org,
	neeraj.soni@oss.qualcomm.com
Subject: Re: [PATCH v1] virtio-blk: Add inline encryption support
Date: Fri, 21 Aug 2026 11:33:51 -0400	[thread overview]
Message-ID: <20260821153351.GB564943@fedora> (raw)
In-Reply-To: <8ee0da17-1d2b-4465-8fd5-3f6ab401d729@oss.qualcomm.com>

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

On Fri, Aug 21, 2026 at 08:49:03PM +0800, Linlin Zhang wrote:
> 
> 
> On 8/21/2026 12:18 AM, Linlin Zhang wrote:
> > 
> > 
> > On 8/20/2026 5:18 AM, Stefan Hajnoczi wrote:
> >> On Fri, Aug 14, 2026 at 07:23:01AM -0700, Linlin Zhang wrote:
> > 
> >>> +\field{enc_characteristics}, or that identifies a key slot into which no key
> >>> +has been provisioned.
> >>> +
> >>> +A driver MUST set \field{data_unit_size_bits} of a VIRTIO_BLK_T_CRYPTO_IN or
> >>> +VIRTIO_BLK_T_CRYPTO_OUT request's \field{crypto_msg} to $log_2$ of the data
> >>> +unit size in bytes associated with the key provisioned in the virtual key
> >>> +slot identified by \field{slot}. Since data unit sizes are reported by
> >>> +VIRTIO_BLK_T_GET_CRYPTO_MODES as a bitmask of \field{le32} elements, a
> >>> +driver MUST NOT set \field{data_unit_size_bits} to a value greater than 31.
> >>> +
> >>> +A driver MUST NOT submit a VIRTIO_BLK_T_CRYPTO_IN or VIRTIO_BLK_T_CRYPTO_OUT
> >>> +request with a zero length \field{data}.
> >>
> >> Does VIRTIO_BLK_T_WRITE_ZEROES need an equivalent
> >> VIRTIO_BLK_T_CRYPTO_WRITE_ZEROES request type? If the driver sends
> >> VIRTIO_BLK_T_WRITE_ZEROES then the device might write zeroes in
> >> plaintext, which isn't what we want.
> >>
> > 
> > Yes, it's still cipher text that is flushed into disk even the driver sends
> > VIRTIO_BLK_T_WRITE_ZEROES. Need add a VIRTIO_BLK_T_CRYPTO_WRITE_ZEROES request
> > type.
> > 
> 
> I double-checked VIRTIO_BLK_T_WRITE_ZEROES. Since a request may consist of
> multiple non-contiguous segments, handling DUN calculation becomes difficult
> if the backend needs to divide the request. Because both sector offset and
> data length per segment need be aligned with Data Unit Size, and only the DUN
> for the first segment can be appended to the crypto message in the virtio reqeust.
> 
> For this reason, I would prefer not to introduce VIRTIO_BLK_T_CRYPTO_WRITE_ZEROES,
> consistent with the treatment of discard/erase requests.
> 
> I'm appreciated if you have any thoughts about it.

The storage stack supports devices that do not have write zeroes
operations, so I don't think there is any problem - except that the
performance benefits of write zeroes are lost.

It's worth adding a sentence to the spec as a reminder that only
VIRTIO_BLK_T_CRYPTO_WRITE/READ are encrypted so drivers must not reach
for write_zeroes, etc since they are not encrypted.

And the Linux driver implementation needs to be careful not to send
write zeroes.

Stefan

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

  reply	other threads:[~2026-08-21 15:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14 14:23 [PATCH v1] virtio-blk: Add inline encryption support Linlin Zhang
2026-08-17 17:16 ` Stefan Hajnoczi
2026-08-18  4:53   ` Linlin Zhang
     [not found] ` <20260819042915.GA9971@sol>
2026-08-19 11:10   ` Linlin Zhang
     [not found] ` <20260819043321.GB9971@sol>
2026-08-19 11:30   ` Linlin Zhang
2026-08-19 19:35     ` Stefan Hajnoczi
2026-08-20 14:37       ` Linlin Zhang
2026-08-19 21:18 ` Stefan Hajnoczi
2026-08-20 16:18   ` Linlin Zhang
2026-08-21 12:49     ` Linlin Zhang
2026-08-21 15:33       ` Stefan Hajnoczi [this message]
2026-08-22 10:04         ` Linlin Zhang
2026-08-21 15:30     ` Stefan Hajnoczi
2026-08-22 10:43       ` Linlin Zhang
  -- strict thread matches above, loose matches on Subject: below --
2026-01-27 14:14 Linlin Zhang
2026-01-27 14:20 ` Linlin Zhang
2026-01-27 21:09   ` Stefan Hajnoczi
2026-01-30 10:23     ` Linlin Zhang
2026-02-02 15:56       ` Stefan Hajnoczi
2026-02-03 10:06         ` Linlin Zhang
2026-02-03 14:43           ` Stefan Hajnoczi
2026-02-04 13:57             ` Linlin Zhang
2026-02-04 17:27               ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260821153351.GB564943@fedora \
    --to=stefanha@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=linlin.zhang@oss.qualcomm.com \
    --cc=neeraj.soni@oss.qualcomm.com \
    --cc=virtio-dev@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox