With the rpm-4.14.3 on SLE-15-SP3, using rpm.open through pcall can
not access the db and SecureBoot efi variable files. We got the
following message when the pretrans lua script is running:
WARNING: Attempt to open db EFI variable file failed. Error message:
attempt to call a nil value
Using io.open instead of pcall(rpm.open can workaround this issue.
With the rpm-4.14.3 on SLE-15-SP3, the string comparison in elif
directive has problem. It causes that the certificate block in the
elif-endif to disappear permanently, regardless of whether the
comparison succeeds or fails.
This change can also workaround the issue that elif can not handle
special issue_hash/subject_hash from 'openSUSE Secure Boot Signkey':
shim> openssl x509 -in factory-secure-boot.crt -inform PEM -noout -subject_hash
babd5674
shim> openssl x509 -in factory-secure-boot.crt -inform PEM -noout -issuer_hash
d29860c3
Directlly put to global define in shim.spec can reproduce issue:
global prjissuer_hash d29860c3
global prjsubjec_hash babd5674
This patch changed codes by using if-endif instead of elif-endif to
workaround the above two problems
The old openssl in SLE-15-SP3 assumes the format of input
certificate is PEM. In d279b0c453 patch, we converted the SUSE
certificates from PEM to DER format for using by Lua in pretrans
script. It causes the openssl command to fail with old openssl.
So we specify the certificate format in openssl commands.
We still need time to test nx (non-executable) shim and develop
the script for delivery. We will not support nx-shim on all Leap
and SLE distros because the function should also be supported by
grub2 and kernel.
A shim_nx macro flag be added to shim.spec to block all sections
for building shim-nx package.
Directly package Microsoft-signed shim when the version of shim
equals with the version of devel shim. The Microsoft-signed shim
can be directly deliveied because we build the binary before and
have the log (shim-review) to prove it.
When the version of build service built shim (aka. devel shim)
does NOT equal to the version of Microsoft-signed shim, it means
we are developing a new shim. We package devel shim instead of
Microsoft-signed shim. The devel shim binary will also be the
candidate for next shim-review.
Remove the reproducibility check for the shim binary before attacing
Microsoft signature. The binutils on Leap 15.6 and SLE-15-SP3 has been
upgraded to 2.45 when we are waiting shim-review and Microsoft signing.
It causes that the shim binary is NOT reproducible on build services.
Which means that the signature of shim from Microsoft can not be
attached on rebuilt shim.
The original design is extract signature from the Microsoft signed back
shim, rebuild shim binary, check the pesign hash of rebuilt shim and
attach Microsoft signature. But in past years, we got at least two times
the bulid service environment be changed when waiting shim-review.
Microsoft doesn't resign shim binary because SUSE build environment be
changed.
In the discussion with Johannes Segitz, he raised the idea from Ludwig
Nussel that we just direct use the Microsoft signed-back shim binaries
because we build this binary before and have the logs to prove it.
Before we find a good approach to save/restore the build service
environment, let’s directly use the Microsoft signed-back shim for
delivery.
This patch removes the reproducibility check logic and all *.asc
signature files.
For checking Microsoft CA keys in UEFI db, let's add
Microsoft_Corporation_UEFI_CA_2011.crt and Microsoft_UEFI_CA_2023.crt
to the target certificates array (TARGET_CERT_HEXES) in pretrans script.
Because shim 16.1 will be signed by them. This is a transitional period
from MS 2011 key to MS 2023 key. We will receive two MS signatures.
On the other hand, in order to pass the QA test on the devel/staging
project. We also add _projectcert.crt key to TARGET_CERT_HEXES. It's
useful for testing our pretrans lua script on staging project.
Add Microsoft UEFI
The download links are from Microsoft document:
Windows Secure Boot Key Creation and Management Guidance, 05/19/2022
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance?view=windows-11
------------------------------------------------------------------------
1. Microsoft Corporation UEFI CA 2011
SHA-1 cert hash: 46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3.
SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
Microsoft will provide the certificate to partners and it can be
added either as an EFI_CERT_X509_GUID or an EFI_CERT_RSA2048_GUID type
signature.
The Microsoft Corporation UEFI CA 2011 can be downloaded from here:
https://go.microsoft.com/fwlink/p/?linkid=321194.
2. Microsoft UEFI CA 2023
SHA-1 cert hash: B5EEB4A6706048073F0ED296E7F580A790B59EAA.
SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
Microsoft will provide the certificate to partners and it can be
added either as an EFI_CERT_X509_GUID or an EFI_CERT_RSA2048_GUID type
signature.
The Microsoft UEFI CA 2023 can be downloaded from here:
https://go.microsoft.com/fwlink/?linkid=2239872.
------------------------------------------------------------------------
Those two Microsoft certificates will be used in TARGET_CERT_HEXES array
in pretrans script for checking UEFI db has necessary public key before
shim installation is started.
We will put more certificates for checking in installation stage. And
We will also include more signature asc files from Microsoft UEFI CA
2023 key. Therefore, the source files were reordered to facilitate
subsequent development. No functional updates.
Base on Microsoft Portable Executable and Common Object File
Format Specification (Revision 10 – June 15, 2016), the size
of CheckSum in Optional Header is 4 bytes. But temstamp.pl
read and write the CheckSum by 2 bytes. This patch fixes this
size issue.
For a long time, the incorrect size of CheckSum in SUSE shim
did not cause any errors in shim/shim-review. This fact implicitly
confirms that CheckSum is useless for shim boot loader. We didn't
see any Windows loader attempting to load shim.
But I still keep CheckSum in timestamp in case there are any use
case haven't discovered yet.
