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

[Glenn Washburn]

On Tue, 01 Feb 2022 15:48:01 +0000
Maxim Fomin <maxim@fomin.one> wrote:

> ------- Original Message -------
> 
> On Monday, January 31st, 2022 at 23:40, Glenn Washburn 
> <development@efficientek.com> wrote:
> 
> > 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.
> >
> > Glenn
> 
> Plainmount can work with '(hdX,gptY)' syntax in config or shell (actually, 
> this
> is the base syntax) and thus it is not limited to GPT paritions, what is 
> limited
> is the ability to use UUID - currently only on GPT. If partition scheme does 
> not
> have UUID then UUID as a convenience feature cannot be supported - 
> inconvenient,
> but technically fair. I will take a look at MBR UUID and see whether they can 
> be
> supported. Possible situations (under current implementaion) are follows:
> 
> a) GPT disk, multi-disk environment, disks map unpredictably: can name 
> partitions
>    by GPT UUID in config file/shell, no problem, ability to name by UUID has 
> value

I agree that searching by partition UUID is useful and desirable.
However, I don't think this is the right approach. GRUB should have
generic searching by partition UUID. There is already a patch for
this[1]. Perhaps you can test/review this patch to help it gain more
visibility and advocate for it being accepted.

Glenn

[1] https://lists.gnu.org/archive/html/grub-devel/2021-04/msg00055.html

> b) GPT disk, single disk environment: no problem, UUID feature has less value
> b) not GPT, single disk environment: no problem, config like 'plainmount 
> (hd0,gpt2)'
>    always works
> d) not GPT, multi-disk environment, disks map unpredictably: worst case, link
>    '(hd0,gpt2)' can randomly fail, but user can type manually in shell
> e) cannot mount plain mode device in grub shell <- this is impossible, 
> plainmount
>    can always be called in shell.
> 
> Best regards,
> Maxim Fomin
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel