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 <pjones@redhat.com>
The license statements in our source files were getting to be a giant
mess, and mostly they all just say the same thing. I've switched most
of it to SPDX labels, but left copyright statements in place (where they
were not obviously incorrect copy-paste jobs that I did...).
If there's some change here you don't think is valid, let me know and
we can fix it up together.
Signed-off-by: Peter Jones <pjones@redhat.com>
One of the really great things about Github IMO is how
"front and center" the README file in a repository is (just
compare with Sourceforge).
Github renders it more nicely if the file is declared to be Markdown,
so let's do that. Add a bit of formatting: using code fences
for code, hyperlinks for other files etc.
I also added a title block from the Fedora package `Summary`
since while I know in theory shim is independent of bootloaders,
let's say what the 95% case is here.
This adds stuff that only ever gets made as an artifact of building
(though build*/ generally doesn't, as of this commit.)
Signed-off-by: Peter Jones <pjones@redhat.com>
This is a backport from devel for:
commit 852091d63f73011742c61c976e40f35edd74d598
Author: Nicholas Bishop <nicholasbishop@gmail.com>
Date: Thu May 17 19:28:53 2018 -0400
Fix typo
Signed-off-by: Peter Jones <pjones@redhat.com>
This was previously on devel as:
commit 2e29c0358888412e9addfb016cc72f6e89ffb536
Author: Peter Jones <pjones@redhat.com>
Date: Mon Jun 29 14:06:34 2020 -0400
Add .cer/.crt/.esl to .gitignore
But .cer and .crt were added independently in another commit since then.
Signed-off-by: Peter Jones <pjones@redhat.com>
Sometimes we're loading structures that are parsed in string-like ways,
but can't necessarily be trusted to be zero-terminated. Solve that by
making sure we always have enough aligned, trailing zero bytes to always
have at least one NUL character, no matter which character type is being
parsed.
Signed-off-by: Peter Jones <pjones@redhat.com>
Add a file that contains example workflows for SBAT and better illustrate
what type of content is expected to be present in both the .sbat section
and the SBAT authenticated EFI variable.
Signed-off-by: Peter Jones <pjones@redhat.com>
SBAT is a new Generation Number Based Revocation meant to replace the DBX
Revocation List Files mechanism. It is more flexible and allow to revoke
sets of binaries, instead of having to list all of them as with the DBX.
Metadata that includes the vendor, product family, product, component,
version and generation are added to artifacts in a .sbat section. This
is protected by the digital signature and so it cannot be tampered.
Signed-off-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Gary Lin <glin@suse.com>
Right now we allocate the PE file's contents in RW memory, but hopefully
that won't always be the case. Our SBAT parsing, however, very much
expects to be able to edit it. We also don't actually know that shim's
.sbat section is loaded r/w, so we can't necessarily write there.
This patch copies the SBAT data to its own buffer, plus one NUL byte at
the end, so we can always be sure that will work.
Signed-off-by: Peter Jones <pjones@redhat.com>
Parse the SBAT [0] Version-Based Revocation Metadata that's contained in a
.sbat data section of the loaded PE binary. This information is used along
with data in a SBAT variable to determine if a EFI binary has been revoked.
[0]: https://github.com/rhboot/shim/blob/sbat/SBAT.md
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Unfortunately GNU-EFI doesn't currently implement ascii versions of
strchr() or strchrnul(), and we kind of need them, so add an
implementation here for now.
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>
This adds the "sbat" branch to the list of branches where a build is
done if a PR is submitted against that branch.
Signed-off-by: Peter Jones <pjones@redhat.com>
This makes each of the f32/f33/f34 distro builds use the same steps to
do the build, as well as making each of them build both x64 and ia32
targets.
Signed-off-by: Peter Jones <pjones@redhat.com>
I renamed PeImage.h to pe.h when I de-capitalized them, but this turns
out to be a bad idea because we already have a pe.h on the SBAT branch.
Woops.
This moves it to peimage.h
Signed-off-by: Peter Jones <pjones@redhat.com>
In the version of clang-format I've got locally[0],
WhitespaceSensitiveMacros seems to only work sometimes. That means that
if we ever run it on some particular things, it could seriously mess up
a bunch of our debugging output. That's not great.
In this patch, I've gone ahead and run clang-format on all the macros
that use __LINE__, which are the obvious places this is dangerous, and
then audited the result and fixed anything that's broken (including a
couple of places where it was already broken.)
[0] random:~/devel/github.com/shim/clang-format$ clang-format --version
clang-format version 11.0.0 (Fedora 11.0.0-2.fc33)
Signed-off-by: Peter Jones <pjones@redhat.com>
clang-format doesn't allow you to specify an include sort order, and
just assumes asciibetical is a pretty good order, which doesn't work as
well as you would hope.
This makes them all lower case so they don't need to be re-sorted.
I also went through and checked that we're using quoted local includes
at all the appropriate places.
Signed-off-by: Peter Jones <pjones@redhat.com>
There's clearly not enough conformance to a single coding style here.
To some extent that can't really change - I don't intend to adopt edk2's
style for the main codebase, but re-formatting the code we borrow from
edk2 would be insane.
This commit adds a .clang-format file, to be used on new files as such:
clang-format --style=file -i foo.c
It can also be used when new free-standing code is added to existing
files, using the clang-format --lines= option.
The starting style in this is pretty close to the Linux kernel style,
with a couple of minor modifications.
Signed-off-by: Peter Jones <pjones@redhat.com>
On systems where a second stage bootloader is not used, and the Linux
Kernel is booted directly from shim, shim's ExitBootServices() hook
can cause problems as the kernel never calls the shim's verification
protocol. In this case calling the shim verification protocol is
unnecessary and redundant as shim has already verified the kernel
when shim loaded the kernel as the second stage loader.
This functionality is disabled by default and must be enabled via the
DISABLE_EBS_PROTECTION macro/define at build time.
Signed-off-by: Paul Moore <pmoore2@cisco.com>