efi-boot-shim.git/lib/guid.c, branch rolling

Implement shim image load protocol

2025-02-11T15:43:37+00:00

Define a new protocol for loading and starting images, encapsulating shim's PE loading facilities and verification/authentication against the same set of certificates that shim_lock::verify() authenticates against. This removes the need for loaders like GRUB to implement their own PE loader in order to be able to invoke loaded images as PE applications, rather than implementing a bespoke OS dependent handover protocol (e.g., invoke Linux via its EFI stub) Signed-off-by: Ard Biesheuvel

BS Variables for bootmgr revocations

2023-12-05T18:20:00+00:00

This adds support for applying SkuSiPolicy UEFI BS variables. These varaibles are needed for non-dbx based Windows revocations and are described here: https://support.microsoft.com/en-us/topic/kb5027455-guidance-for-blocking-vulnerable-windows-boot-managers-522bb851-0a61-44ad-aa94-ad11119c5e91 Signed-off-by: Jan Setje-Eilers

Enable TDX measurement to RTMR register

2022-08-16T21:45:30+00:00

Intel Trust Domain Extensions (Intel TDX) extends Virtual Machine Extensions (VMX) and Multi-Key Total Memory Encryption (MK-TME) with a new kind of virtual machine guest called a Trust Domain(TD)[1]. A TD runs in a CPU mode that is designed to protect the confidentiality of its memory contents and its CPU state from any other software, including the hosting Virtual Machine Monitor (VMM). Trust Domain Virtual Firmware (TDVF) is required to provide Intel TDX implementation and service for EFI_CC_MEASUREMENT_PROTOCOL[2]. The bugzilla for TDVF is at https://bugzilla.tianocore.org/show_bug.cgi?id=3625. To support CC measurement/attestation with Intel TDX technology, these 4 RTMR registers will be extended by TDX service like TPM/TPM2 PCR: - RTMR[0] for TDVF configuration - RTMR[1] for the TD OS loader and kernel - RTMR[2] for the OS application - RTMR[3] reserved for special usage only Add a TDX Implementation for CC Measurement protocol along with TPM/TPM2 protocol. References: [1] https://software.intel.com/content/dam/develop/external/us/en/documents/tdx-whitepaper-v4.pdf [2] https://software.intel.com/content/dam/develop/external/us/en/documents/tdx-virtual-firmware-design-guide-rev-1.pdf [3] https://software.intel.com/content/dam/develop/external/us/en/documents/intel-tdx-guest-hypervisor-communication-interface-1.0-344426-002.pdf Signed-off-by: Lu Ken [rharwood: style pass on code and commit message] Signed-off-by: Robbie Harwood

PE Loader: support and require NX

2022-05-17T23:01:03+00:00

This adds support in our PE loader for NX support utilizing the EFI_MEMORY_ATTRIBUTE protocol. Specifically, it changes the loader such that: - binaries without the EFI_IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag set in the Optional Header are rejected as EFI_UNSUPPORTED - binaries with non-discardable sections that have both the EFI_SCN_MEM_WRITE and EFI_SCN_MEM_EXECUTE flags set are rejected as EFI_UNSUPPORTED - if the EFI_MEMORY_ATTRIBUTE protocol is installed, then: - sections without the EFI_SCN_MEM_READ flag set will be marked with EFI_MEMORY_RP - sections without the EFI_SCN_MEM_WRITE flag set will be marked with EFI_MEMORY_RO - sections without the EFI_SCN_MEM_EXECUTE flag set will be marked with EFI_MEMORY_XP Signed-off-by: Peter Jones

SPDX: Clarify the attribution for James's lib/ code

2021-02-16T08:12:48+00:00

At the time, this was explicitly contributed under the Tiano license, even though the original code[0] is LGPLv2.1. [0]: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git Signed-off-by: Peter Jones

Also use a config table to mirror mok variables.

2020-07-26T02:14:08+00:00

Everything was going just fine until I made a vendor_db with 17kB of sha256 sums in it. And then the same source tree that had worked fine without that threw errors and failed all over the place. I wrote some code to diagnose the problem, and of course it was a failure in mirroring MokList to MokListRT. As Patrick noted in 741c61abba7, some systems have obnoxiously low amounts of variable storage available: mok.c:550:import_mok_state() BS+RT variable info: MaximumVariableStorageSize:0x000000000000DFE4 RemainingVariableStorageSize:0x000000000000D21C MaximumVariableSize:0x0000000000001FC4 The most annoying part is that on at least this edk2 build, SetVariable() /does actually appear to set the variable/, but it returns EFI_INVALID_PARAMETER. I'm not planning on relying on that behavior. So... yeah, the largest *volatile* (i.e. RAM only) variable this edk2 build will let you create is less than two pages. It's only got 7.9G free, so I guess it's feeling like space is a little tight. We're also not quite preserving that return code well enough for his workaround to work. New plan. We try to create variables the normal way, but we don't consider not having enough space to be fatal. In that case, we create an EFI_SECURITY_LIST with one sha256sum in it, with a value of all 0, and try to add that so we're sure there's /something/ there that's innocuous. On systems where the first SetVariable() / QueryVariableInfo() lied to us, the correct variable should be there, otherwise the one with the zero-hash will be. We then also build a config table to hold this info and install that. The config table is a packed array of this struct: struct mok_variable_config_entry { CHAR8 name[256]; UINT64 data_size; UINT8 data[]; }; There will be N+1 entries, and the last entry is all 0 for name and data_size. The total allocation size will always be a multiple of 4096. In the typical RHEL 7.9 case that means it'll be around 5 pages. It's installed with this guid: c451ed2b-9694-45d3-baba-ed9f8988a389 Anything that can go wrong will. Signed-off-by: Peter Jones Upstream: not yet, I don't want people to read this before Wednesday. Signed-off-by: Peter Jones

Don't have tons of local guid definitions for no reason at all.

2018-03-12T20:21:43+00:00

Signed-off-by: Peter Jones

Make lib/ build right with the cflags it should be using...

2015-04-13T23:55:25+00:00

... but isn't. Signed-off-by: Peter Jones

Add nostdinc to the CFLAGS for lib

2014-12-11T14:48:50+00:00

We don't need the headers from the standard include path. Signed-off-by: Gary Ching-Pang Lin

Merge signature.h into efiauthenticated.h and guid.h

2013-09-26T15:58:02+00:00

Conflicts: shim.c