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

[Leah Rowe]

Hi Denis,

On Thu, 18 Jan 2024 00:50:57 +0100
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:

> 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.

In which case, they will use whatever their distro supports.

> 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.

Makes sense so far, but my understanding is that those users will
likely only have pbkdf2, right?

> 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.

However, I fail to see how this relates to the GNU Boot project, or
indeed any coreboot distro that uses GRUB. We can provide argon2, and
then that is available for users.

If a user is on a distro that provides GRUB_ENABLE_CRYPTODISK=y, then
they will likely configure PBKDF2 instead of Argon2, unless that distro
has Argon2 support in its version of GRUB. In that case, the same setup
would work in your GRUB, because it would still support PBKDF2.

The issue I see here is that you are still using GRUB 2.06 anyway,
which is full of bugs that GRUB 2.12 fixes. In my view, the argon2
patches are very much desirable, and you've yet to convince me.
However, I will still answer the rest of the email.

> 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.

This will be a good solution, but the problem is we can't predict how
they'll merge it. I've personally vetted that code myself and checked
it against PHC, it seems like a solid port of the code.

I would agree that this is a very precarious solution, and it's not
something that we should be spending time on.

> - Fork GRUB just to add this Argon2 patch, and ideally other small
>   patches as well.

In fact, I have that exact agenda, though I've not yet started the
work. I want a fork of GRUB that closely monitors upstream, merging its
improvements whenever possible, while slowly diverging, to become a
bootloader specifically optimised for use as a coreboot payload. It
would do away with a lot of the legacy code in GRUB, and provide only
what is needed for coreboot users.

It would remain compatible with the real GRUB, re-using its
configuration files. One of the main problems I find with GRUB is that,
due to it being portable among many architectures and platforms, the
code, while very well generalised, can sometimes be a bit esoteric.
Finding you way around the source (especially machine init) is
cumbersome.

The other criticism I have is of the build system. It's using arcane
autoconf (surprise surprise), a Kconfig-based build system like
coreboot/linux would be better. Instead of compiling and calling
grub-mkimage or grub-mkstandalone directly, you would configure for the
target and just type make.

This would enable both GNU Boot and Libreboot to better integrate it,
re-using the build logic for coreboot (because it would be the same
logic, calling menuconfig and so on).

> - Upstream the Argon2 patch and few other patches as well inside GRUB
>   directly.

Yes, I think this option is best, but I see no reason why we can't
review and merge these patches early. Perhaps sharing our findings with
upstream? I already did send a message to grub-devel about this, and
there was some discussion.

> 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.

This is a real risk, but I think for the volume of the code (it's not a
lot of code, and seems to integrate well with GRUB's existing
cryptodisk framework), I think we can audit it ourselves.

The *issue* I think is when upstream starts changing around some of its
cryptodisk code, that might be a problem later when updating GRUB
revisions, but we'll cross that bridge.

> > 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.

Ok, that makes sense.

> 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.

Yes, you have to review it yourself for now. As I said, we can share
our findings with upstream and get it merged. Last I checked, they were
already considering bringing it in. I was told however that it would
not be in a release until GRUB 2.14; I asked a little while before the
GRUB 2.12 release, unsure when it would be released.

> 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.

Why not just keep sync with upstream, and use their revisions? I happen
to use 2.12 right on the dot, but I regularly use git revisions in
between releasse, at least in Libreboot I do. There's no reason why GNU
Boot can't do that.

And I do in fact go through every commit. When I update revisions, I
actually check every new commit from upstream. I actually read the
diffs. This is something that should always be done, in my view.

(and it's why I like to update revs often, so that I'm not reviewing
thousands of diffs between two stable releases)

> - 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.
> 

But the distributions are defaulting to argon2 kdf anyway, on LUKS2
setups. By the way, don't just look at my argon2 merge, look at the
grub.cfg changes I made too. They make cryptodisk booting work more
automatically.

> 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).

That is also quite possible to do.

> > 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).

Which is why GNU Boot should integrate the argon2 patches.

>   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.

Why would we break the user's machine? From what I can understand,
either they're using argon2 and GRUB wouldn't boot it(coreboot GRUB),
or you have the argon2 patches present, and then it works.

> - 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.

Look at my grub.cfg patch :)

It specifically addresses this, by more aggressively scanning for
encrypted disks. I've been using it myself, on my own machines, and
actually shipping it to people who buy my laptops.

> 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.

Once again, this makes no sense. I can't see the problem here.

Anyway, it's your project. Do as you will.

-- 
Leah Rowe,
Company Director,
Minifree Ltd

Registered in England, registration No. 9361826
VAT Registration No. GB202190462
Minifree Ltd, 19 Hilton Road, Canvey Island
Essex SS8 9QA, United Kingdom
United Kingdom

pgpIyfnvyGw3K.pgp
Description: PGP signature