grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] plainmount: Support decryption of devices encrypted in p


From: Milan Broz
Subject: Re: [PATCH 1/2] plainmount: Support decryption of devices encrypted in plain mode.
Date: Tue, 1 Feb 2022 08:16:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1

On 01/02/2022 03:45, Glenn Washburn wrote:
On Mon, 31 Jan 2022 17:40:24 +0000
Maxim Fomin <maxim@fomin.one> wrote:

------- Original Message -------

On Monday, January 31st, 2022 at 14:15, Milan Broz <gmazyland@gmail.com> wrote:

On 30/01/2022 20:40, Maxim Fomin wrote:

This patch introduces support for plain encryption mode (plain dm-crypt) via

new module and command named 'plainmount'. The command allows to open devices

encrypted in plain mode (without LUKS) with following syntax:

+

...

+#define GRUB_PLAINMOUNT_UUID "00000000000000000000000000000000"

+#define GRUB_PLAINMOUNT_CIPHER "aes-cbc-essiv:sha256"

+#define GRUB_PLAINMOUNT_DIGEST "ripemd160"

+#define GRUB_PLAINMOUNT_KEY_SIZE 256

+#define GRUB_PLAINMOUNT_SECTOR_SIZE 512

Sooner or later we will have to change this default in cryptsetup

(as ripemd and CBC mode are no longer the best options) and you

you will create data corruption here (as there is no way in plain

mode to check that the mode is set correctly).

Not sure if it is possible, but in normal system it should be required

that these parameters are set in /etc/crypttab, grub should perhaps

require explicit setting them in config too?

Milan

These default values can be fixed or removed altogether. Some additional points.

1. Just to clarify - mounting device in plain mode with wrong parameters (it is 
irrelevant
whether default values or explicitly set arguments are wrong) does not case 
data corruption
per se, data corruption requires writing to such device. And writing to 
unformatted device
is complicated by the fact that no command operating on files will work with 
such device.
User can corrupt data only if he uses some grub command which has functionality 
to write
arbitrary byte data to arbitrary device (like 'dd' command) at arbitrary device 
offset.

I agree. I don't think data corruption is a big issue because GRUB
doesn't (generally) write to disks.

Yes, what I meant is in some situations like when the encryption use 4k sectors 
while
default here is 512Bytes. Then you can have the first 512B decrypted correctly
(the rest 7 512B sectors is garbage, as it fits in 4k larger sector - depends 
on IV setting).
This is enough to detect FS signature but obviously not correct data.
(In most real cases you get garbage in the whole sector.)

It is perhaps ok to ignore it, though.

...
I'm fine with default arguments, _if_ the defaults are common (eg. if
cryptsetup has defaults use those). As a user of plainmount, I think
I'd want to always be explicit incase the defaults changed. Of course,
not having defaults is okay too.

FYI: The defaults from patch are default for plain device in cryptsetup since
version 1.1.0 (2010).
But we have to change it soon, perhaps in 2.5 release.

Milan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]