[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about GRUB/GELI support
From: |
Andrei Borzenkov |
Subject: |
Re: Question about GRUB/GELI support |
Date: |
Sat, 27 Sep 2014 10:15:57 +0400 |
В Fri, 26 Sep 2014 13:11:36 -0400
Kris Moore <address@hidden> пишет:
>
> 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!
>