Re: [PATCH v1] virtio-blk: Add inline encryption support

On 8/21/2026 11:33 PM, Stefan Hajnoczi wrote:
> 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.
> 

Thanks!

I agree with you, and follow your advice to add bellow in in
\drivernormative{\subsubsection}{Device Operation}{Device Types / Block Device / Device Operation}

  - If the driver would otherwise use a virtual key slot's inline encryption
    to encrypt the data written to a range of the device backend storage,
    the driver MUST NOT submit a VIRTIO_BLK_T_WRITE_ZEROES request for that
    range: doing so would cause literal zero bytes to be written to the
    device backend storage, bypassing the inline crypto engine, which a
    later VIRTIO_BLK_T_CRYPTO_IN request covering the same range would then
    misinterpret as ciphertext. The driver MUST instead submit a
    VIRTIO_BLK_T_CRYPTO_OUT request whose \field{data} consists entirely of
    zero bytes, so that the device backend storage receives properly
    encrypted ciphertext for that range.

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

Yes. The current Linux implementation already handles this correctly
in Linux File System (FS). Linux FS, which is the primary user of
inline encryption, distinguishes between fscrypt and non-fscrypt
requests, so VIRTIO_BLK_T_WRITE_ZEROES can only be issued through the
non-fscrypt path and is never used for encrypted I/O.

> Stefan