Re: [PATCH 0/3] Add support for signing grub with an appended signature

[Daniel Axtens <dja@axtens.net>]

[This bounced from the list for some reason, so I'm trying again.]

Hi Michal,

That's a really interesting proposal - thank you. I'm still thinking
about it and experimenting with it in SLOF.

Some thoughts:

> It has been pointed out in the plumbers session that the ELF note will
> cause problems when user wants to add additional signature.
>
> The normal appended signature has only one size information - in the
> footer at the end of the binary, and that is not part of the signed
> data. So if you want to add additional signature it if possible to
> expand the room for the signature data.

The appended signature metadata doesn't contain information about the
size of the signed data. It contains the size of the PKCS#7/CMS
signature block - because that can change in size based on the hash
function and the identity of the signing certificate.

Normally this doesn't matter: you can get a size of the whole file from
the filesystem and then because you know the size of the appended
signature data, you can work out the size of the signed data.

> In contrast the ELF note size is present in the ELF header which is
> also signed. This does not allow adjusting the size of the signature
> data once the binary is signed.

Correct. We could potentially allocate lots of space, but you are
correct that the size of the ELF note is fixed by the signature.

> A simpler scheme would be for grub-install to parse the signature
> footer, split-off the signature, write the ELF binary at the start of
> the PReP partition, and the signature at the end. Then the grub
> signature can use exactly same format as the kernel and modules.

I got part way through implementing this today in SLOF and realised that
it's not immediately clear what the size of the signed data is for
verifying the appended signature - that is, how much of the PReP
partition should I be hashing? As I said, the appended signature
metadata doesn't encode this particular size value.

One thing that we might be able to do is to base the size of the
verified data on a size calculated from the ELF header: basically figure
out the maximum file offset + size for all the program headers, capped
at (partition size - appended signature size), and hash that many
bytes. If I understand correctly, and assuming grub-mkimage constructs
valid ELF files, this should be correct.

I'll give this a go in SLOF tomorrow, and I'll also need to confer with
the team that develops the proprietary firmware used by PowerVM.

> The disadvantage is that for signed grub dd is no longer an alternative
> to grub-install.
>
> There was also concern about distinguishing signed and un-signed grub.
> That is that writing an un-signed grub might lease a stale signature
> leading to an error.
>
> However, secure boot is something that should be enabled or disabled in
> firmware settings, and not triggered by the PPeP partition containing a
> signature. 
>
> When secure boot is enabled checking the grub signature is required and
> un-signed grub is invalid. When secure boot is disabled the signature
> is irrelevant and stale signature should not cause any error.

What I'm concerned about here - and it's possible I explained it poorly
at Plumbers - is how a systems administrator would distinguish between
having accidentally installed an unsigned grub, and having installed a
grub with a broken or untrusted signature.

Having said that, ...

> grub-install can also remove the signature magic when installing
> un-signed grub for consistency. Users using dd to install un-signed
> grub might still have an old signature at the end of the partition.

if we make grub-install do the right thing, I think that sufficiently
mitigates my concern.

Thanks again, and I'll let you know how I get on shortly.

Kind regards,
Daniel