All of lore.kernel.org
 help / color / mirror / Atom feed
From: Glenn Washburn <development@efficientek.com>
To: Maxim Fomin <maxim@fomin.one>
Cc: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH 0/2] Support plain encryption mode.
Date: Tue, 1 Feb 2022 18:51:06 -0600	[thread overview]
Message-ID: <20220201185106.4be9b679@crass-HP-ZBook-15-G2> (raw)
In-Reply-To: <W1oVWzuL_4DOZxEF8G09dyggpOlyHallciSg5Za0LKHler_7zN-_udnTcT3Fh8JqP9uGn7h0OKFHPMbWJcbRtFIWfwHPHQtVdKKQ81lslE8=@fomin.one>

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


  reply	other threads:[~2022-02-02  0:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-30 19:40 [PATCH 0/2] Support plain encryption mode Maxim Fomin
2022-01-31 20:40 ` Glenn Washburn
2022-02-01 15:48   ` Maxim Fomin
2022-02-02  0:51     ` Glenn Washburn [this message]
2022-02-02 15:00       ` Maxim Fomin
2022-02-04 16:34         ` Glenn Washburn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220201185106.4be9b679@crass-HP-ZBook-15-G2 \
    --to=development@efficientek.com \
    --cc=grub-devel@gnu.org \
    --cc=maxim@fomin.one \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.