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

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

[Michal Suchánek]

Hello,

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.

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.

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.

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.

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.

Thanks

Michal

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

[Daniel Axtens]

[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

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

[Daniel Axtens]

Hi Michal,

>> 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.
>

I talked to the firmware team this morning.

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.

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

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

[Michal Suchánek]

Hello,

thanks for looking into this

On Thu, Oct 22, 2020 at 03:25:33PM +1100, Daniel Axtens wrote:
> Hi Michal,
> 
> >> 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.
> >
> 
> I talked to the firmware team this morning.
> 
> 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.

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.

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.

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

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

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

[Michal Suchánek]

On Fri, Oct 23, 2020 at 04:33:58PM +1100, Daniel Axtens wrote:
> 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.

And you need to know about the format of the data to make use of it -
specifically to execute it as an ELF binary, anyway.

> 
> > 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.

Adding the flag is something optional, and otherwise the data passed is
the same.

If you read PReP either pass the whole thing if it is smaller than 32MB
or you pass the first 32MB and append the signature (if it exists), and
there is quirky case when the signature crosses the boundary of your
'maximum binary size'. This quirky case is caused by another layering
violation - the code is reading something it does not understand from
the partition.

Thanks

Michal

> 
> 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

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

[Daniel Axtens]

Part of a secure boot chain is allowing boot firmware to verify the
grub core.img. For UEFI platforms, this is done by signing the PE
binary with a tool like pesign or sb-sign. However, for platforms that
don't implement UEFI, an alternative scheme is required.

These patches provide some infrastructure and documentation for
signing grub's core.img with a Linux-kernel-module style appended
signature.

Because some platforms, such as powerpc-ieee1275, load grub from a raw
disk partition rather than a filesystem, we extend grub-install to add
an ELF note that allows us to specify the size and location of the
signature.

More details are in patch 1, including a link to an open-source firmware
capable of verifying a grub image signed this way.

Daniel Axtens (2):
  docs/grub: Document signing grub under UEFI
  docs/grub: Document signing grub with an appended signature

Rashmica Gupta (1):
  Add suport for signing grub with an appended signature

 docs/grub.texi              | 64 ++++++++++++++++++++++++++++++++++++-
 include/grub/util/install.h |  8 +++--
 include/grub/util/mkimage.h |  4 +--
 util/grub-install-common.c  | 16 ++++++++--
 util/grub-mkimage.c         | 11 +++++++
 util/grub-mkimagexx.c       | 39 +++++++++++++++++++++-
 util/mkimage.c              | 10 +++---
 7 files changed, 138 insertions(+), 14 deletions(-)

-- 
2.25.1

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

[Daniel Axtens]

Hi,

> Part of a secure boot chain is allowing boot firmware to verify the
> grub core.img. For UEFI platforms, this is done by signing the PE
> binary with a tool like pesign or sb-sign. However, for platforms that
> don't implement UEFI, an alternative scheme is required.
>
> These patches provide some infrastructure and documentation for
> signing grub's core.img with a Linux-kernel-module style appended
> signature.
>
> Because some platforms, such as powerpc-ieee1275, load grub from a raw
> disk partition rather than a filesystem, we extend grub-install to add
> an ELF note that allows us to specify the size and location of the
> signature.

This is following up on the discussion out of Linux Plumbers [1].
Hopefully I've got the main question-askers, apologies if I've missed
anyone or sent emails to the wrong people. I'm also emailing grub-devel@
in hopes of catching anyone else who is interested.

One of the big requirements I heard was a desire to support key
rotation, for example by being able to embed multiple signatures in a
single signed grub.

I checked, and this is possible with appended signatures as I have
proposed them, because the size of the full signature block is known
when grub-mkimage is called.

You do have to do a bit of magic with openssl and sign-file, but it's
not particuarly bad. This demonstrates the openssl side and it's easy
to integrate with grub-mkimage:

# sign data/hello-world with both signing1 and signing2, placing just the
# PKCS#7 message in out/double-sig.p7s
openssl cms -sign -binary -in data/hello-world \
    -signer signing1.pem -inkey signing1.key \
    -signer signing2.pem -inkey signing2.key \
    -out out/double-sig.p7s -outform DER -noattr -md sha512

# append it to data/hello-world using sign-file's -s option, creating
# out/hello-world-sha512-2keys
../tools/sign-file -s out/double-sig.p7s sha512 /dev/null data/hello-world out/hello-world-sha512-2keys

# to verify, extract the cryptographic message with
# extract-module-sig.pl from the kernel source

./extract-module-sig.pl -s out/hello-world-sha512-2keys > out/hello-world-sha512-2keys.sig 2> /dev/null
if ! cmp out/double-sig.p7s out/hello-world-sha512-2keys.sig ; then
	echo "Input signature and data from extract-module-sig.pl -s do not agree!"
	exit 1;
fi

# openssl's verify requires that _both_ signatures are made with
# embedded certs which validate against a trusted CA
openssl cms -verify -binary -in out/hello-world-sha512-2keys.sig -inform der \
            -content hello-world -CAfile ca.pem -out /dev/null
if [ $? -ne 0 ]; then
	echo "OpenSSL failed to verify with both keys"
	exit 1
fi

For our application, firmware will allow a grub binary to boot if any
of the signatures in the PKCS#7 message match a key that is trusted by
firmware. This should allow keys to be rotated with firmware releases
without breaking backwards compatibility.

I've updated https://github.com/daxtens/SLOF to demonstrate this: if
any signature can be validated by a built-in key, it will pass
verification.



Another thing that was raised was the ability to make multiple
signatures separated in time, where the second signer didn't have
access to the private keys for the first signer. The example given was
for someone to sign a distro binary with a second set of keys
(e.g. specific keys for a data center) - then the binary would be
bootable on machines with distro keys, and also on machines that have
only the second set of keys.

This is not so easy. For grub, with the elf note, the data over which
the signature is made contains the size of the signature. To add a
signature would be to change the size of the signature stored in the
signed data. That would either break the old signature, or we would need
to make it not a true appended signature any more: rather than being a
'dumb' signature over everything before the start of the appended
signature data, it'd be more complex. We'd need to teach the signer and
verifier how to deal with that, and then we've thrown away the
advantages of appended signatures and reinvented many of the
complexities of Authenticode.

One thing we could potentially do without going down that route is to
include a quantity of 'blank space' for signatures - we could for
example always allocate a few kilobytes for signatures. The distro
signatures would take up the first part of the buffer, leaving space
for some for 'user' signatures.

We can get this to work with the appended-signature format "as is": we
specify how big the PKCS#7 message is, and if the message happens to be
smaller than the size we give, both openssl and mbedtls will just ignore
any trailing data.

This does at least kinda-sorta work, but OpenSSL's 'cms -resign' command
only works if we include signed attributes and at the moment our mbedtls
implementation cannot handle that. I don't think the PKCS#7 standard
mandates that behaviour, so maybe we can hack around it with the OpenSSL
C API. Or maybe we can extend mbedtls to handle signed
attributes. (eek!)

The concern I have is that this approach creates a big block of
arbitrary unsigned data in the grub binary. An attacker under our threat
model (root on the host) could put any data they like into that space. I
worry that in combination with some other vulernability, this could be
used to more easily pass useful data in to grub. However, maybe that's
not that much of a win for the attacker: if they are root they also have
complete control of grub.cfg and can instruct grub to do quite a bit as
it is.

I'm also not sure that the use-case is quite as likely with Power
systems vs x86 systems. But if I'm overthinking the security
implications of a blank space in the binary, it seems like we could get
it to work and I'd be happy to chase it up further.

Thoughts? (on or off-list is fine.)

Kind regards,
Daniel

[1] https://linuxplumbersconf.org/event/7/contributions/738/
    https://youtu.be/IJUNxHnopH4?t=537

> More details are in patch 1, including a link to an open-source firmware
> capable of verifying a grub image signed this way.
>
> Daniel Axtens (2):
>   docs/grub: Document signing grub under UEFI
>   docs/grub: Document signing grub with an appended signature
>
> Rashmica Gupta (1):
>   Add suport for signing grub with an appended signature
>
>  docs/grub.texi              | 64 ++++++++++++++++++++++++++++++++++++-
>  include/grub/util/install.h |  8 +++--
>  include/grub/util/mkimage.h |  4 +--
>  util/grub-install-common.c  | 16 ++++++++--
>  util/grub-mkimage.c         | 11 +++++++
>  util/grub-mkimagexx.c       | 39 +++++++++++++++++++++-
>  util/mkimage.c              | 10 +++---
>  7 files changed, 138 insertions(+), 14 deletions(-)
>
> -- 
> 2.25.1