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>

When calling back into shim from grub, the MokListRT may contain additional
entries not available in the original MokList, an example being the certs
included via user_cert. Use the MokListRT instead when calling check_db_cert
and check_db_hash.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

It's been suggested that we should link to the test plan in the readme.
This seems pretty reasonable to me, so here it is.

Signed-off-by: Peter Jones <pjones@redhat.com>

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 <ken.lu@intel.com>
[rharwood: style pass on code and commit message]
Signed-off-by: Robbie Harwood <rharwood@redhat.com>

In 6c8d08c ("shim: Ignore UEFI
LoadOptions that are just NUL characters."), a check was added to
discard load options that are entirely NUL.  We now see some firmwares
that start LoadOptions with a NUL, and then follow it with garbage (path
to directory containing loaders).  Widen the check to just discard
anything that starts with a NUL.

Resolves: #490
Related: #95
See-also: https://bugzilla.redhat.com/show_bug.cgi?id=2113005
Signed-off-by: Robbie Harwood <rharwood@redhat.com>

We've seen crashes in early GRUB code on an ARM Cortex-A72-based
platform that point at seemingly harmless instructions. Flushing
the i-cache of those instructions prior to executing has been
shown to avoid the problem, which has parallels with this story:
  https://www.mail-archive.com/osv-dev@googlegroups.com/msg06203.html

Add a cache flushing utility function and provide an implementation
using a GCC intrinsic. This will need to be extended to support other
compilers. Note that this intrinsic is a no-op for x86 platforms.

This fixes issue #498.

Signed-off-by: dann frazier <dann.frazier@canonical.com>

0214cd9 fixes a NULL pointer dereference problem, it introduces two
new problems.  First it incorrectly assumes li.FilePath is a string.
Second, it puts EFI_LOADED_IMAGE li on the stack. It has been found
that not all archectures can handle this being on the stack.

The shim_li variable will be setup properly from the read_image
call. Use the global shim_li variable instead when calling
verify_image.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

Use the EFI RT memory function CopyMem instead of memcpy in load_cert_file.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

This changes the alignment of UINT64 data to 8 bytes on IA32, which
matches EDK2's understanding of alignment. In particular this change
affects the offset where shim writes `EFI_LOADED_IMAGE.ImageSize`.

Fixes #515

Signed-off-by: Nicholas Bishop <nicholasbishop@google.com>

Seen mokmanager image load failure '2 sections contain entry point'
for shim built on Oracle Linux 9 aarch64. found_entry_point counter in
handle_image() uses SizeOfRawData to calculate section boundary.
PE spec defines VirtualSize for the total size of the section when loaded
into memory. SizeOfRawData is the size of the section (for object files)
or the size of the initialized data on disk.

Fix this issue by updating section in-memory size limit to VirtualSize.

Resolves: #517
Signed-off-by: Ilya Okomin <ilya.okomin@oracle.com>

Remove timestamps, user names, etc. from the tarball so that
it can be built reproducibly by multiple people, on different
machines.

The outer bzip2 layer might still be different, no reproducible
bzip2 known.

Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>

MokListTrusted was added by mistake to PCR 7 in 4e51340. The value of
MokListTrusted does not alter the behavior of secure boot so, as per
https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_v23_pub.pdf#page=36
(section 3.3.4 PCR usage) so it should not be factored in the value of
PCR 7.

See:
  #423
  4e51340

Fixes #484
Fixes #492

Signed-off-by: Arthur Gautier <arthur.gautier@arista.com>

AuthenticodeVerify() calls OpenSSLs d2i_PKCS7() API to parse asn encoded
signed authenticode pkcs#7 data. when this successfully returns, a type
check is done by calling PKCS7_type_is_signed() and then
Pkcs7->d.sign->contents->type is used. It is possible to construct an asn1
blob that successfully decodes and have d2i_PKCS7() return a valid pointer
and have PKCS7_type_is_signed() also return success  but have Pkcs7->d.sign
be a NULL pointer.

Looking at how PKCS7_verify() [inside of OpenSSL] implements checking for
pkcs7 structs it does the following:
- call PKCS7_type_is_signed()
- call PKCS7_get_detached()
Looking into how PKCS7_get_detatched() is implemented, it checks to see if
p7->d.sign is NULL or if p7->d.sign->contents->d.ptr is NULL.

As such, the fix is to do the same as OpenSSL after calling d2i_PKCS7().
- Add call to PKS7_get_detached() to existing error handling

Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Cherry-picked-from: tianocore/edk2@26442d1

This adds a few more UEFI functions to our coverity model, so we see a
few less false positives during scanning.  It also fixes an error in our
model for OpenSSL's OBJ_dup().

Signed-off-by: Peter Jones <pjones@redhat.com>

Though we don't need to bump SBAT_LEVEL for this, we've decided to
change the level to 3 here in case
53509ea turns out to be worse than we
think it is, so we can fix that easily later.

Signed-off-by: Peter Jones <pjones@redhat.com>

Due to the issues addressed in the 2022-11-15 batch of grub CVEs[0], we
need to bump the sbat version from grub.  This patch changes it from 2
to 3.

[0] https://lists.gnu.org/archive/html/grub-devel/2022-11/msg00059.html

Signed-off-by: Peter Jones <pjones@redhat.com>

Signed-off-by: Peter Jones <pjones@redhat.com>