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: 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