linux-kernel - Re: [discussion] proposal to bypass zero data for dm-crypt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <34ddb616-63c7-5423-b20f-4ccd61bc4a66@huaweicloud.com>
Date: Mon, 6 Jan 2025 09:43:38 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: Milan Broz <gmazyland@...il.com>, Mikulas Patocka <mpatocka@...hat.com>
Cc: Alasdair Kergon <agk@...hat.com>, Mike Snitzer <snitzer@...nel.org>,
 dm-devel@...ts.linux.dev, Yu Kuai <yukuai1@...weicloud.com>,
 lkml <linux-kernel@...r.kernel.org>, "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [discussion] proposal to bypass zero data for dm-crypt

Hi,

在 2025/01/06 4:54, Milan Broz 写道:
> 
> On 1/3/25 5:25 PM, Mikulas Patocka wrote:
>> Milan, what do you think about this from a cryptographic point of view?
>> Does it make sense to add an option that would detect zero data and skip
>> decryption in this case?
> 
> It is a very dangerous thing.
> 
> Disk encryption is a length-preserving encryption, so it cannot prevent
> decryption of modified ciphertext. However, such ciphertext modification
> (without key knowledge) will cause a pseudorandom plaintext output
> (IOW attacker cannot easily flip bits or whole sectors by ciphertext
> modification).
> 
> If you allow the zeroed sector to transform to valid plaintext directly,
> the attacker can wipe arbitrary plaintext sector. It can lead to fatal
> issues (for example, wiping filesystem metadata bitmaps on some known
> location).

Will there be difference if the attacher wipe the data to zero data or
random data? And AFAIK, for this case, should user consider dm-integrity
to prevent such attack?

> 
> Stack FDE (dm-crypt) below the filesystem or other storage layer
> (like thin provision) that supports sparse data, and you will get
> the expected behavior without such tricks.

All we want to do is to offer an additional option for user, to enable
dm-crypt or not. And if we stack dm-crypt below our storage layer, then
all users will have to use dm-crypt. In order to prevent that, the
storage layer will have to be much complex, and it will be impossible
to perform a hot upgrade without affecting existing use cases. :(

Thanks,
Kuai

> 
> Milan
> 
> 
>>
>> Mikulas
>>
>> On Sat, 21 Dec 2024, Yu Kuai wrote:
>>
>>> Background
>>>
>>> We provide virtual machines for customers to use, which include an 
>>> important
>>> feature: in the initial state, the disks in the virtual machine do 
>>> not occupy
>>> actual storage space, and the data read by users is all zeros until 
>>> the user
>>> writes data for the first time. This can save a large amount of storage.
>>>
>>> Problem
>>>
>>> However, after introducing dm-crypt, this feature has failed. Because we
>>> expect the data read by users in the initial state to be zero, we 
>>> have to
>>> write all zeros from dm-crypt.
>>>
>>> Hence we'd like to propose to bypass zero data for dm-crypt, for
>>> example:
>>>
>>> before:
>>> zero data -> encrypted zero data
>>> decrypted zero data -> zero data
>>> others
>>>
>>> after:
>>> zero data -> zero data
>>> decrypted zero data -> encrypted zero data
>>> others(doesn't change)
>>>
>>> We'd like to hear from the community for suggestions first, before we
>>> start. :)
>>>
>>> Thanks,
>>> Kuai
>>>
>>
> 
> .
>