grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 0/2] Support plain encryption mode.


From: Glenn Washburn
Subject: Re: [PATCH 0/2] Support plain encryption mode.
Date: Mon, 31 Jan 2022 14:40:18 -0600

On Sun, 30 Jan 2022 19:40:37 +0000
Maxim Fomin <maxim@fomin.one> wrote:

> This patch adds support for plain encryption mode (plain dm-crypt) via new
> module/command named 'plainmount'. This is an extension of previous patch
> (member of crypto enhancement patch series) sent to grub-devel by John Lane.
> The plain mode patch was fully reworked, the most important changes are:
> 
> 1. The code is rewritten as a separate 'plainmount' module and command. This
> change addresses several issues raised in previous patch discussion: complex
> implementation and expanding too much cryptomount parameter list. Plainmount
> module still depends on several functions in cryptodisk module just like LUKS,
> LUKS2 and geli modules. I tried to minimize link to cryptodisk, but some link
> is unavoidable.
> 
> 2. Plainmount now uses GPT partition unique UUID to point to exact partition.
> Plain mode does not have special header (as LUKS/LUKS2 does), so it does not
> have any UUID. Absence of UUID was key issue in discussions of original plain
> mode patch - without UUID any link like 'hdX,gptY' in grub.cfg can be broken
> in multiboot setup because hdX can map to different disks each boot.

So plain mount can only be used for volumes located on GPT partitions,
leaving out MBR or any other partitioning format, full-disk encryption,
and loopback file encryption. I think this is an undesirable and
unnecessary limitation.

Instead, I suggest assuming the user knows what they are doing in the
GRUB shell/script and letting them do it. This should not be allowed
when automatically generating the grub.cfg using GRUB user-space tools.
GRUB should fail to automagically install to a device hosted on a plain
encrypted container (unless perhaps an override is given). I suspect
that this is the default, but worth mentioning.

> 3. The patch brings support for keyfiles and using disk blocks as a keyfile.
> This functionality was added in cryptodisk module (and thus was available for
> plain mode) via other patch from 'crypto enhancement' patch series. Thus all
> features from original patch series are available in plainmount module (except
> detached header which is LUKS only feature and multiple password attempts 
> which
> are undefined in plain mode). The patch also brings support for large blocks
> (1024/2048/4096 byte).
> 
> Some issues are still not resolved. Although the problem with UUID is solved,
> no changes were made in grub-install or grub-mkconfig. Currently user must
> manually edit grub.cfg to add plainmount command.

I think this is fine.

> Also, inserting plainmount
> in standalone grub does not work because plainmount needs crypto arguments.
> Theoretically they can be stored somewhere in efi core image - in this case
> plain mode can be fully supported like LUKS. Currently user must manually edit
> grub.cfg to use plainmount (or manually type in console). Still, this helps in
> some use cases (including some complex setup scenarios). Also, except opening
> plain mode encrypted disks plainmount command can decrypt LUKS volumes if
> master key is known.

On the next iteration of this patch series, please use --thread to git
format-patch and git send-email.

Glenn

> Maxim Fomin (2):
>   plainmount: Support decryption of devices encrypted in plain mode.
>   plainmount: Document new command syntax and options.
> 
>  docs/grub.texi              |  52 +++
>  grub-core/Makefile.core.def |   5 +
>  grub-core/disk/plainmount.c | 678 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 735 insertions(+)
>  create mode 100644 grub-core/disk/plainmount.c
> 
> --
> 2.35.1
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



reply via email to

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