Re: Question about GRUB/GELI support

[Andrei Borzenkov <arvidjaar@gmail.com>]

В Fri, 26 Sep 2014 13:11:36 -0400
Kris Moore <kris@pcbsd.org> пишет:

> 
> Hey, quick question about GRUB's support for GELI. We are using it to
> boot Free/PC-BSD with GELI v5, and it works great there. However FreeBSD
> updated their geli implementation very slightly to v7, which only
> changes which part of the master key is used for encrypt / decrypt.
> 
> https://github.com/freebsd/freebsd/commit/38de8ef1dd0e468ff1e3ec1c431f465e270beba3
> 
> I think the line in GRUB that needs tweaking is on or around 440 of
> grub-core/disk/geli.c, where it calls grub_crypto_pbkdf2 (dev->hash.....

It would be too simple ... :) It just unlocks master key itself, while
patch makes GELI to use derived key during encryption (and I presume
decryption).

> I'm having trouble figuring out which part of that would be the
> equivalent of Freebsd's mkey -> ekey change, or if that data is even
> exposed in GRUB's version. Any tips or pointers?
> 

You need to change which key is used for decryption after

      /* Set the master key.  */
      if (!dev->rekey)
        {
...

Now, after cursory browsing of FreeBSD code, grub geli seems to lack
quite a number of flags, each one apparently changing how keys are
computed. I do not know enough about GELI to decide whether they are
important to support or not. But I tried to understand where
sc->sc_ekey comes from in case of G_ELI_FLAG_SINGLE_KEY not set, and failed :)

Also it seems that sc->sc_ekey is computed differently depending on
whether G_ELI_FLAG_AUTH is set or not (if it is not set, ekey is
apparently just a copy of mkey sans IV).

> I'm also doing some other patches to GRUB so we can pass the GELI key as
> a variable to the kernel, skipping the prompting at mount-root. That
> seems to work well, but I wanted to see if I could knock out both fixes
> at the same time. Once its done, I'll be happy to forward the patch for
> upstream inclusion.
> 

It's up to you but I do not see any reason to wait as long as two
patches address independent problems.

> Thanks!
>