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 --]
next prev parent reply other threads:[~2026-08-21 15:34 UTC|newest]
Thread overview: 29+ 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-25 23:34 ` Stefan Hajnoczi
2026-08-28 13:08 ` Linlin Zhang
2026-08-31 20:04 ` Stefan Hajnoczi
[not found] ` <20260827184905.GC2137493@google.com>
2026-08-28 15:47 ` 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
2026-08-24 15:44 ` Stefan Hajnoczi
2026-08-28 8:29 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.