efi-boot-shim.git - (mirror of https://github.com/vyos/efi-boot-shim.git)

Age	Commit message (Collapse)	Author
2021-02-12	efi bins: add an easy way for vendors to add .sbat data	Peter Jones
	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>
2021-02-12	Add a .sbat section to EFI binaries	Javier Martinez Canillas
	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>
2017-02-23	Make shim_version live in a special aligned section.	Peter Jones
	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>
2015-06-29	Make sure our build-id notes wind up at a reasonable place.	Peter Jones
	Signed-off-by: Peter Jones <pjones@redhat.com>
2015-06-29	Add a conditional point for a debugger to attach.	Peter Jones
	Signed-off-by: Peter Jones <pjones@redhat.com>
2013-06-10	Move embedded certificates to their own section.	Peter Jones
	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 23 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 000aa7e1 000000000001d000 000000000001d000 00017a00 24 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .reloc 0000000a 00000000000c8000 00000000000c8000 000c2200 20 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .data 00031228 00000000000c9000 00000000000c9000 000c2400 25 CONTENTS, ALLOC, LOAD, DATA 4 .vendor_cert 00000375 00000000000fb000 00000000000fb000 000f3800 20 CONTENTS, READONLY 5 .dynamic 000000f0 00000000000fc000 00000000000fc000 000f3c00 23 CONTENTS, ALLOC, LOAD, DATA 6 .rela 0002afa8 00000000000fd000 00000000000fd000 000f3e00 23 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .dynsym 0000f1f8 0000000000128000 0000000000128000 0011ee00 23 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>