| Age | Commit message (Collapse) | Author |
|---|
|
In d972515e608e ("Save the debug and error logs in mok-variables") had a
few deficiencies: 1) the size of the result table isn't correctly
computed when either errlog or dbglog is 0 sized (much more likely for
the former), 2) when we save the error log we leak the allocation for
the previous mok variables, and 3) original mok variables were allocated
with AllocatePages(), but the new ones were allocated with
AllocateZeroPool(). The former guarantees page alignment, which we want
here.
This fixes all three of these.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
hughsie asked me to also make it observable at runtime whether the shim
binary that was used to boot was set as NX_COMPAT or not.
This adds that into the HSIStatus data as "shim-has-nx-compat-set".
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This adds three more entries to our HSI data:
has-dxe-services-table: technically only tells us if UEFI's
LocateProtocol will give us a DXE services
table, but practically also tells us if the
machine is implementing DXE in any way.
has-get-memory-space-descriptor: tells us if DXE->GetMemorySpaceDescriptor
is populated
has-set-memory-space-descriptor: tells us if DXE->SetMemorySpaceDescriptor
is populated
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Previously the mok mirror state flags were only used in the mok
mirroring code. But there are other consumers of that data, namely our
variable test cases, and it's useful for them to be able to check the
flags.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
hughsie asked me if I can make shim tell userland what kinds of accesses
are allowed to the heap, stack, and allocations on the running platform,
so that these could be reported up through fwupd's Host Security ID
program (see https://fwupd.github.io/libfwupdplugin/hsi.html ).
This adds a new config-only (i.e. not a UEFI variable) variable
generated during boot, "/sys/firmware/efi/mok-variables/HSIStatus",
which tells us those properties as well as if the EFI Memory Attribute
Protocol is present.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This adds a member to the mok_state_variable struct to provide a
callback function for formatting external data. It basically has
snprintf()-like semantics for filling the buffer, but without the actual
printf-like formatting bits.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This adds a mok variable flag "MOK_VARIABLE_CONFIG_ONLY" to specify that
the data should be added to our UEFI config table, but shim should not
create a legacy UEFI variable.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
This adds a new MoK variable, MokPolicy (&MokPolicyRT) that's intended
as a bitmask of machine owner policy choices, and the bit
MOK_POLICY_REQUIRE_NX. This bit specifies whether it is permissible to
load binaries which do not support NX mitigations, and it currently
defaults to allowing such binaries to be loaded.
The broader intention here is to migrate all of the MoK policy variables
that are really just on/off flags to this variable.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
|
Heavily inspired by Matthew Garrett's patch "Allow additional certificates
to be loaded from a signed binary".
Add support for loading a binary, verifying its signature, and then
scanning it for embedded certificates. This is intended to make it
possible to decouple shim builds from vendor signatures. In order to
add new signatures to shim, an EFI Signature List should be generated
and then added to the .db section of a well-formed EFI binary. This
binary should then be signed with a key that shim already trusts (either
a built-in key, one present in the platform firmware or
one present in MOK) and placed in the same directory as shim with a
filename starting "shim_certificate" (eg, "shim_certificate_oracle").
Shim will read multiple files and incorporate the signatures from all of
them. Note that each section *must* be an EFI Signature List, not a raw
certificate.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
|
|
This lets us access the definitions for this structure, and the data
being used at runtime, from unit tests.
Signed-off-by: Peter Jones <pjones@redhat.com>
|
