Re: GNU Boot patches: update to GRUB 2.12 with various fixes

[Denis 'GNUtoo' Carikli]

On Sun, 14 Jan 2024 19:55:33 +0000
Leah Rowe <info@minifree.org> wrote:
> The distro's GRUB isn't executed, when a GRUB payload is used in
> coreboot, so I don't fully understand your reasoning. Can you explain?

If users use GNU Boot with SeaBIOS (either with 'seabios' or
'seabios_withgrub' payloads) then GRUB is provided by the GNU/Linux
distribution and not by GNU Boot.

With that setup, with MBR a first stage of GRUB is installed to
the MBR. If GPT is being used instead the first stage and/or the grub
image is installed to a partition with an id of ef02. 

And so when 'GRUB_ENABLE_CRYPTODISK=y' is enabled users don't need a
boot partition anymore as the support for opening encrypted volumes is
added directly in that first stage.

The problem is that GNU Boot doesn't provide that GRUB, the
distribution provides them. And supporting SeaBIOS with LUKS encryption
and without /boot is also a valid use case. I personally use it on some
of my computers for instance. That GRUB feature is also advertised in
the documentation of some GNU/Linux distributions, so users (me
included) use that.

So my question is how do we protect these users?

If we follow my logic here and that we want to protect all users, and
not just users using GRUB payloads inside very few boot software
distributions like GNU Boot, Libreboot, etc, then we would need the
Argon2 support to land in all GNU/Linux distributions.

And so I see only 3 solutions for that:
- Try to convince all the distributions around there to add a patch for
  Argon2. I don't think this is a good option.
- Fork GRUB just to add this Argon2 patch, and ideally other small
  patches as well.
- Upstream the Argon2 patch and few other patches as well inside GRUB
  directly.

I think that the last option is at the same time the best one and the
one that requires the least amount of efforts.

The first two options also increase the risk of other kinds of attacks
as we'd be shipping code that was not reviewed by upstream and that
might have memory safety issues.

> I did contact grub-devel, and Daniel Kiper told me that this would
> likely be available by the timeof the GRUB 2.14 release. The 2.12
> release only just came out, and GRUB usually only does a release every
> few years, so you will be waiting years before that is possible. It's
> already been years since those argon patches were made for GRUB, and
> they haven'tbeen merged yet.
Thanks for the information.

> I've noticed a general tendency for GRUB to not merge patches. It
> literally takes years, under the project's current leadership
> (understaandable given the scope of the project and the limited
> manpower relative to it).
I'm unsure if this is still an issue. I saw that happening when I tried
to upstream patches for LUKS detached keys and several factors slowed
down the merging of the patches:
- The project was working to fix security issues that weren't public.
  As I understand, this slowed down the project *a lot*.
- The crypto subsystem needed to be reworked and this was done as part
  of this patchset.
- I also had big cleanups to do and I had limited time so the time
  between the patch revision was big.

Note that this was also a collective effort by several people over
time.

> Those patches have been in use on GRUB 2.06 for years, distributed on
> the archlinux user repository. The code in question is the reference
> implementation by PHC (password hash competetion), which is likely
> safe.
The problem is also how can I be sure without at the end having to
review the code myself.

And we don't necessarily need to wait years to use newer GRUB
revisions. Once the code is upstream, two strategies are possible:
- If the dependencies of the changes are small, it would be possible to
  backport the patches and review the diff between the backport and the
  files that are upstream.

- If the dependencies of the changes are big we can simply use
  non-release git hash.

Of course it won't fix all GNU/Linux distributions, but at some point
all this problem will go away as distributions use newer GRUB versions.

In these two cases it would also be way easier to convince some users
and/or distributions to use/ship GRUB with Argon2 by using one of these
two schemes and having an alternative GRUB package (grub-git, package
from backports, etc).

> Not having argon2 support in GRUB is a bad idea. The alternative is
> for the user to have an unencrypted /boot, or downgrade to older KDF
> like PBKDF2 (and thus be vulnerable to GPU attacks), which is not
> ideal.
It's not ideal indeed. Having it in GRUB proper somehow would fix part
of this mess for everybody. 

Another part that is missing in most distributions is to somehow upgrade
the LUKS volumes to more recent schemes when users upgrade their
packages or to a new distribution version.

There are two parts in that:

- One is for LUKS volumes with system partitions inside. Tails did it,
  but adding something like that now in more generic/configurable
  distributions would probably break the boot for users using
  'GRUB_ENABLE_CRYPTODISK=y' unless Argon2 makes it in the GRUB of that
  distribution (and its downstream forks too, not to break them).

  And so we pretty much need that support almost everywhere not to break
  users setups as users can have multiple distributions in one single
  LUKS partition through various ways.

- Another issue is removable disks for sharing data, and there the
  scheme probably needs to be updated when opening the partition. Here
  it also raises the issue with more LUKS implementations like FreeOTFE
  if that still exists.

So if we want that fixed for good and for everybody, including less
technical users or users without the time to learn about it and type
scary commands (to update the LUKS volume), we need to land support for
Argon2 upstream at some point.

This way when all still-supported distributions / LUKS implementations
will finally support Argon2, it will be possible to enable/add support
to automatically update the LUKS volumes.

Denis.

pgpPNReElNnBp.pgp
Description: OpenPGP digital signature