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