| Age | Commit message (Collapse) | Author |
|---|
|
Build changes to generate include/generated_sbat_var_defs.h from
SbatLevel_Variable.txt and use that header file. From here on
forward SbatLevel_Variable.txt should be the only place a new
revocation needs to be recorded.
Signed-off-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
|
|
Back in January we decided to bump the SBAT level for the shim
CVE without bumping the grub level for the previous NTFS issues
- CVE-2023-4692 CVE-2023-4693 - as not every vendor was signing
the ntfs module.
Catch up on this revocation to ensure it doesn't get lost. Doing
so also allows us to remove the grub.debian,4 revocation as this
happened before grub,4 and hence is obsolete.
Also bump the date of the sbat variable to today's. Don't copy
the April 5 one to a previous selection, as it wasn't shipped
to anyone.
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
|
|
Add the previous latest level to the switch for automatic.
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
|
|
The ability to automatically apply SBATLevel revocations varies
from distro to distro. This allows distros that are able to
automatically apply SBATLevel revocations when shim is updated to
select a level by supplying SBAT_AUTOMATIC_DATE=<datestamp> on the
make command line. Currently the following options are available:
2021030218 no revocations - useful for distros that need to rely on
an externally delivered revocations.efi
2022052400 grub,2
2022111500 shim,2
grub,3
2023012900 shim,2
grub,3
grub.debian,4
If no datestamp is specified the build will default to the
most recent 2023012900.
Signed-off-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
|
|
When the term previous was introduced for revocations to be
automatically applied there was a hope that everytime a new
revocation was built into shim, the previous revocation could
be applied automatically. Further experience has shown the
real world to be more complex than that. The automatic payload
will realistically contain a set of revocations governed by
both the cadence at which a distro's customer base updates
as well as the severity of the issue being revoked.
This is not a functional change.
Signed-off-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
|
|
Since shim is inherently updated by shipping a new shim, the
latest built in revocations can include the most recent shim
revocations. Since CVE-2023-40547 is high impact, this revocation
should be available to everyone as soon as possible.
GRUB2 CVE-2023-4692 and CVE-2023-4693 are in the ntfs module that
only some vendors ship. Since some vendors did not ship an updated
GRUB2 for these issues, the revocation for these CVEs is not
included in the payload at this time.
Signed-off-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
|
|
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 <Jan.SetjeEilers@oracle.com>
|
|
Ingest SBAT Levels from revocations binary thereby allowing level
requirements to be updated independently from shipping a new shim.
Do not automatically apply any revocations from a stock shim at
this point.
Signed-off-by: Jan Setje-Eilers <Jan.SetjeEilers@oracle.com>
|
|
(See https://bugs.debian.org/1024617)
One of the Debian builds of grub bumped the SBAT to 3, but didn't
include the patches needed. Add "grub.debian,4" to block those
binaries.
Signed-off-by: Steve McIntyre <steve@einval.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>
|
|
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>
|
