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

[Daniel Axtens]

Hi Michal,

>> So grub is usually loaded from the PReP partition if you are booting
>> from disk. But, if you are booting from a CD/USB/etc, we first parse
>> /ppc/boot-info.txt and then load whatever file it identifies. If you're
>> netbooting we load the file we get from the network.
>> 
>> One strength of the ELF-note based scheme is that verification of the
>> appended signature is exactly the same in all these scenarios, and in
>> each case it can live entirely in the ELF parsing and loading code.
>> 
>> In contrast, if we don't have an elf note, we have to handle PReP
>> partitions, CHRP boot-info.txt and netboot separately. At least in the
>> PReP case we also have to do parse enough of the ELF header to determine
>> how much data we need to be hashing for signature verification, and this
>> crosses a couple of previously separate steps of the process.
>> 
>> To illustrate from SLOF, currently the ELF note stuff lives almost
>> entirely in elf32.c, but for the scheme you describe we need to patch
>> load-from-dos-boot-partition, load-from-gpt-prep-partition, whatever
>> code we use for where we boot a file directly from disk for CHRP
>> boot-info.txt loading, and something somewhere in the netboot code.
>
> Why do you have to handle different boot media separately, though?
>
> There is this bug, supposedly in 'old firmware' that when the PReP
> partition is large (gigabytes in size) the firmware crashes trying to
> load the whole thing to memory and hand it over to the elf parser. If
> this is fixed today you need to parse the header anyway to know how much
> to load, or you need to just hand over some handle to the partition and
> let the elf parser do the reading.

Hmm, I will pass this on to the enterprise/proprietary Partiton Firmware
(PFW) team to confirm that it's been fixed.

It won't affect (at least modern versions of) SLOF, as SLOF caps the
amount of PReP partition that it reads at 32MB. It reads min(partition
size, 32MB) and passes that to the ELF loader. (I suppose that will
break if a bootloader ever grows to be > 32MB, but most distros only
allocate something like 8MB to PReP today, so you'd hit partition size
limits first anyway.)

> The appended signature format is exactly the same in each case: there is
> a container such as a partition, a file, or a block of memory that has
> an elf binary at the start, optional padding, and optinal signature at
> the end. There is nothing stopping the elf parser from parsing both
> the elf header and the signature footer when it gets the data.

Reflecting on it, the proposed new design is also pretty quirky.

The existing appended signature format is:

 data || pkcs7 || metadata || magic

If you strip off the signature, only the data remains, which you can
immediately calculate the hash on and verify the signature. The ELF note
format perserves this property.

Moving the signature to the end of the PReP partition gives you:

  data || [padding] || pkcs7 || metadata || magic

Once you've stripped off the signature, you now need an extra processing
step to strip off the padding. And - unusually for appended signatures -
you need to know about the format of the data to distinguish data from
padding.

> In the case of the partition containing the elf binary it is expected
> that the padding is non-zero, in the other cases having padding is
> suspicious.
>
> In the case of a partition you have to read the data in some
> device-specific sectors while files can be read at arbitrary sized
> chunks.
>
> If you choose to write separate code to fetch the elf binary from
> different media due to these differences then these separate code paths
> must be adjusted. However, that is inherent to lack of suitable
> abstraction in the code, and not the appended signature format.
>
> I think it is more productive to clean up the code to handle all media
> the same way rather than inventing new unique quirky and deficient
> signature format.

You would need to handle the new padding at some stage in the pipeline,
and that pipeline stage needs to know how to read an ELF header. So I
agree that it would be logical to put signature verification in the ELF
parsing stage.

However, if you want to flag the existence of padding in non-PReP cases
- either to reject it or warn about it - then the signature verifier
needs to know if it's parsing a PReP partition. If the signature
validation lives in the ELF parser, you now need to tell the ELF parser
that you are parsing a PReP partion. This seems like an abstraction or
layering problem - the ELF parser shouldn't need to know or care where
the ELF binary comes from.

So I think that merely cleaning up the code wouldn't be sufficient.

Kind regards,
Daniel

>
> Thanks
>
> Michal
>
>> 
>> We can still support multiple signers disjoint in time with the scheme I
>> suggest at
>> https://lists.gnu.org/archive/html/grub-devel/2020-09/msg00081.html
>> although I do agree it's ugly in its own separate way.
>> 
>> Kind regards,
>> Daniel
>> 
>> >> 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