On 2019-04-03, Dominik 'Rathann' Mierzejewski <dominik(a)greysector.net>
wrote:
On Wednesday, 03 April 2019 at 21:30, Chris Murphy wrote:
> On Wed, Apr 3, 2019 at 2:58 AM Dominik 'Rathann' Mierzejewski
> <dominik(a)greysector.net> wrote:
> >
> > On Thursday, 28 March 2019 at 17:30, Ben Cotton wrote:
> > > On Mon, Mar 25, 2019 at 4:12 PM Ben Cotton <bcotton(a)redhat.com>
wrote:
> > > >
> > > >
https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2
> > > >
> > > This Change proposal is on hold.
> >
> > Too bad. As a long-time SecureBoot user, I was looking forward to being
> > able to have encrypted /boot on Fedora.
>
> I'm not sure if this has anything to do with why it's on hold, but
> GRUB does not support LUKS2. And there are no TPM bindings supported
> in LUKS1, but are in LUKS2. In order to get to full disk encryption
> out of the box by default with automatic unlock (measured boot to
> obtain the cryptographic key from the TPM), needs LUKS2. So in effect
> that means we either need GRUB to support LUKS2, or settle on an
> unencrypted /boot.
Well, why can't we have LUKS1-encrypted /boot and enter the encryption
password by hand? That's still better than unencrypted /boot.
What's the point of encrypting /boot? All the executed bits from /boot
(grub, kernel, and initramdisk) are measured by TPM. Thus if somebody
tampers them, root file system decryption that uses TPM will fail.
-- Petr