| Age | Commit message (Collapse) | Author |
|---|
|
Given a set of EFI variables and boot assets, it should be possible
to compute what the value of PCR 7 will be on the next boot.
As shim manages the contents of the SbatLevel variable and this is
measured to PCR 7, export the payloads that shim contains in a new
COFF section (.sbatlevel) so that it can be introspected by code
outside of shim.
The new section works a bit like .vendor_cert - it contains a header
and then the payload. In this case, the header contains no size fields
because the strings are NULL terminated. Shim uses this new section
internally in set_sbat_uefi_variable.
The .sbatlevel section starts with a 4 byte version field which is
not used by shim but may be useful for external auditors if the
format of the section contents change in the future.
Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
|
|
Our section headers on arm binaries need to include .sbat on fallback
and MokManger, and currently they do not.
The reason for this is that gnu-efi provides static, (mostly) hand-coded
section headers on arm and aarch64, due to having no efi-app-arm and
efi-app-aa64 target support in binutils. Additionally, the assembler
also generates (IMO pointless) relocations for _esbat/_sbat_size when
those are actually inside the section, and relocated symbols can't be
used in our section headers.
This patch moves the .sbat section to be after _edata, so the sections
don't overlap, and moves _esbat and _sbat_size to be after the section,
to avoid the relocation.
I'm not 100% sure we can't have overlapping sections, but now doesn't
seem like the time to find out.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
At the default -Os optimization level, gcc emits ".text.startup"
and ".text.unlikely" sections for static initializers and noreturn
functions which end up in the intermediate ELF binary:
$ objdump -h build-x64/shimx64.efi.so
build-x64/shimx64.efi.so: file format elf64-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00046e7b 0000000000001000 0000000000001000 00001000 2**10
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .text.startup 00000118 0000000000047e7b 0000000000047e7b 00047e7b 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .text.unlikely 00000046 0000000000047f93 0000000000047f93 00047f93 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .data 000315e8 0000000000048000 0000000000048000 00048000 2**9
These additional .text.* sections are omitted from the final PE/COFF
binary, resulting in a crash when processing the ctors. Taking a look at
_init_array in gdb:
(gdb) p/x &_init_array
$1 = 0x78510
(gdb) p/x &_init_array_end
$2 = 0x7851c
(gdb) x/x (void*)&_init_array
0x78510 <_init_array>: 0x00047e7b
(gdb) x/x (void*)(&_init_array)+8
0x78518 <_init_array+8>: 0x00000000
See that 0x00047e7b falls inside the padding between the .text and .data
sections:
$ objdump -h build-x64/shimx64.efi
build-x64/shimx64.efi: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00046e7b 0000000000001000 0000000000001000 00000400 2**10
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 000315e8 0000000000048000 0000000000048000 00047400 2**9
Adjust the linker script to merge the .text.startup and .text.unlikely
sections in to the .text section.
[edited by pjones to use .text.* instead of naming the sections
individually, and to sync up with what other arches have in .text]
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
In cases where we accept vendor shim binaries with additional patches,
it may become necessary to identify those builds with additional SBAT
data. When we consider such patches, we should be proactive in asking
vendors to include that data in the .sbat sections of their trusted EFI
binaries.
This patch adds any data in data/sbat.*.csv (after a quick sanitizing
pass) after data/sbat.csv in the .sbat section, so that no changes to
the upstream data/sbat.csv are ever required.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
The Secure Boot Advanced Targeting (SBAT) [0] is a Generation Number Based
Revocation mechanism that is meant to replace the DBX revocation file list.
Binaries must contain a .sbat data section that has a set entries, each of
them consisting of UTF-8 strings as comma separated values. Allow to embed
this information into the fwupd EFI binary at build time.
The SBAT metadata must contain at least two entries. One that defines the
SBAT version used and another one that defines the component generation.
This patch adds a sbat.csv that contains these two entries and downstream
users can override if additional entries are needed due changes that make
them diverge from upstream code and potentially add other vulnerabilities.
The same SBAT metadata is added to the fallback and MOK manager binaries
because these are built from the same shim source. These need to have SBAT
metadata as well to be booted if a .sbat section is mandatory.
[0]: https://github.com/rhboot/shim/blob/sbat/SBAT.md
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
|
|
When I added 4990d3f I inadvertantly made .data.ident and .rela.got
sections appear in the top-level section headers at file offsets not
aligned with PE->OptionalHeader.FileAlignment. This results in a
section table that looks like:
Sections:
Idx Name Size VMA LMA File off Algn
0 .eh_frame 00018648 0000000000005000 0000000000005000 00000400 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .text 00093f45 000000000001e000 000000000001e000 00018c00 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .reloc 0000000a 00000000000b2000 00000000000b2000 000acc00 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .data.ident 000000e4 00000000000b3040 00000000000b3040 000ace40 2**5
CONTENTS, ALLOC, LOAD, DATA
4 .data 000291e8 00000000000b4000 00000000000b4000 000ad200 2**5
CONTENTS, ALLOC, LOAD, DATA
5 .vendor_cert 000003e2 00000000000de000 00000000000de000 000d6400 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .dynamic 000000f0 00000000000df000 00000000000df000 000d6800 2**3
CONTENTS, ALLOC, LOAD, DATA
7 .rela 0001aef8 00000000000e0000 00000000000e0000 000d6a00 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rela.got 00000060 00000000000faef8 00000000000faef8 000f1af8 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .dynsym 0000ecd0 00000000000fb000 00000000000fb000 000f1e00 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
rather than:
Sections:
Idx Name Size VMA LMA File off Algn
0 .eh_frame 00018118 0000000000005000 0000000000005000 00000400 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .text 00091898 000000000001e000 000000000001e000 00018600 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .reloc 0000000a 00000000000b0000 00000000000b0000 000aa000 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .data 00028848 00000000000b1000 00000000000b1000 000aa200 2**5
CONTENTS, ALLOC, LOAD, DATA
4 .vendor_cert 00000449 00000000000da000 00000000000da000 000d2c00 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .dynamic 00000100 00000000000db000 00000000000db000 000d3200 2**3
CONTENTS, ALLOC, LOAD, DATA
6 .rela 0001ae50 00000000000dc000 00000000000dc000 000d3400 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .dynsym 0000ea78 00000000000f7000 00000000000f7000 000ee400 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
(Note "File off" on sections #3 and #8 on the top one.)
This seems to work fine with edk2's loader and shim's loader, as well as
their Authenticode implementation, and pesign's as well.
While PE loaders seem to be fine with sections with alignments smaller
than PE->OptionalHeader.FileAlignment, MS's signtool.exe does ...
something else with them. I'm not sure what. What it definitely does
*not* do is extend the digest based on their file offset and size.
So just don't allow anything that small, and don't allow anything
smaller than SectionAlignment either, just to be on the safe side.
Since most of our stuff gets stripped into the debuginfo anyway, and
shim has relatively few sections, this should not be a very large
burden.
So just to be clear:
If you have a binary with a section that's not aligned on
PE->OptionalHeader.FileAlignment:
- pesign hashes it to A
- tiano hashes it to A
- shim hashes it to A
- signtool.exe hashes it to B
Because that makes sense.
This patch works around the bug in signtool.exe .
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This makes it so two builds of the same .deb on different hosts won't
have wildly different file offsets.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Revert "Do the same for ia32..."
and "Generate a sane PE header on shim, fallback, and MokManager."
This reverts commit 6744a7ef8eca44948565c3d1244ec931ed3f6fee.
and commit 0e7ba5947eb38b79de2051ecf3b95055e620475c.
These are premature and I can do this without such drastic measures.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
It turns out a7249a65 was masking a second problem - on some binaries,
when we actually don't have any base relocations at all, binutils'
"objcopy --target efi-app-x86_64" is generating a PE header with a base
relocations pointer that happily points into the middle of our text
section. So with shim processing base relocations correctly, it refuses
to load those binaries.
For example, on one binary I just built:
00000130 00 a0 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 |................|
which says there's a Base Relocation Table at 0xa000 that's 0xa bytes long.
That's here:
0000a000 58 00 29 00 00 00 00 00 48 00 44 00 28 00 50 00 |X.).....H.D.(.P.|
0000a010 61 00 72 00 74 00 25 00 64 00 2c 00 53 00 69 00 |a.r.t.%.d.,.S.i.|
0000a020 67 00 25 00 67 00 29 00 00 00 00 00 00 00 00 00 |g.%.g.).........|
0000a030 48 00 44 00 28 00 50 00 61 00 72 00 74 00 25 00 |H.D.(.P.a.r.t.%.|
So the table is:
0000a000 58 00 29 00 00 00 00 00 48 00 |X.).....H. |
That wouldn't be so bad, except those binaries are MokManager.efi,
fallback.efi, and shim.efi, and sometimes they're .reloc, which we're
actually trying to handle correctly now because grub builds with a real
and valid .reloc table. So though I didn't think there was any hair
left on this yak, more shaving ensues.
With this change, instead of letting objcopy do whatever it likes, we
switch to "-O binary" and merely link in a header that's appropriate for
our binaries. This is the same method Ard wrote for aarch64, and it
seems to work fine in either place (modulo some minor changes.)
At some point this should be merged into gnu-efi instead of carrying our
own crt0-efi-x86_64.S, but that's a less immediate problem.
I did not need this problem.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
With this change, the embedded certificate and dbx lists (vendor_cert,
vendor_cert_size, vendor_dbx, and vendor_dbx_size) wind up being in a
section named .vendor_cert, and so will look something like:
------
fenchurch:~/devel/github.com/shim$ objdump -h shim.efi
shim.efi: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .eh_frame 000174a8 0000000000005000 0000000000005000 00000400 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .text 000aa7e1 000000000001d000 000000000001d000 00017a00 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .reloc 0000000a 00000000000c8000 00000000000c8000 000c2200 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .data 00031228 00000000000c9000 00000000000c9000 000c2400 2**5
CONTENTS, ALLOC, LOAD, DATA
4 .vendor_cert 00000375 00000000000fb000 00000000000fb000 000f3800 2**0
CONTENTS, READONLY
5 .dynamic 000000f0 00000000000fc000 00000000000fc000 000f3c00 2**3
CONTENTS, ALLOC, LOAD, DATA
6 .rela 0002afa8 00000000000fd000 00000000000fd000 000f3e00 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .dynsym 0000f1f8 0000000000128000 0000000000128000 0011ee00 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
------
This simplifies a security audit, because it means that different
versions of shim with substantially the same code with different keys
will be more easily comperable, and therefore logic differences may be
more easily identified.
This also means that if there's a trusted build you want to use, you can
remove the certificates, implant new ones, and have it signed, and the
code sections won't change.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
