# Secure Boot ## Key Generation & Handling ### Environment _PRODUCTION_: For prod env, download a official Flatcar image, and generate the keys and then import the keys into the Azure Key vault. _DEVELOPMENT_: For development env, download a nightly Flatcar image, and generate the keys and then import the keys into the Azure Key vault _TESTING_: For testing feel free to run the steps in your machines, and then import the keys into a testing Azure Key vault with your name in the keyvault name --- #### Generate Keys & Certificates --- ``` # For production: # Turn off shell history for some commands. export HISTCONTROL=$HISTCONTROL:ignorespace # Create a temporary directory mkdir -m 0700 -p $PWD/flatcar-ca/ # Initialize a NSS database inside the directory. When prompted for a password, create a empty password i.e. press <Enter> certutil -d $PWD/flatcar-ca -N # Create CA efikeygen -d $PWD/flatcar-ca --ca --self-sign --nickname='Flatcar Container Linux Secure Boot Development CA' --common-name='CN=Flatcar Container Linux Secure Boot Development CA' # Azure CLI version: # create the JSON policy for CSR cat <<EOF > policy.json { "issuerParameters": { "certificateTransparency": null, "name": "Unknown" }, "keyProperties": { "curve": null, "exportable": false, "keySize": 4096, "keyType": "RSA", "reuseKey": true }, "secretProperties": { "contentType": "application/x-pkcs12" }, "x509CertificateProperties": { "ekus": [ "1.3.6.1.5.5.7.3.3" ], "subject": "CN=Flatcar Container Linux Secure Boot Development Signing", "validityInMonths": 120 } } EOF # create the CSR using the JSON policy az keyvault certificate create --vault-name chewi-test --name flatcar-sb-signing --policy @policy.json # get the CSR az keyvault certificate pending show --vault-name chewi-test --name flatcar-sb-signing | jq -r .csr | base64 -d > flatcar-sb-signing.csr # convert the CSR to DER openssl req -in flatcar-sb-signing.csr -outform DER -out flatcar-sb-signing.der # sign the signing key CSR by the root CA certutil -C -m 2345 -i flatcar-sb-signing.der -o flatcar-sb-signing-signed-csr.crt -c "Flatcar Secure Boot CA" -d ~/flatcar-ca/ # convert the certificate back to PEM openssl x509 -in flatcar-sb-signing-signed-csr.crt -out flatcar-sb-signing-signed-csr.pem # merge the certificate (this will automatically enable it as well) az keyvault certificate pending merge --vault-name chewi-test --name flatcar-sb-signing --file flatcar-sb-signing-signed-csr.pem ## Testing with sbsign gentoo-vm ~/sbsign # PKCS11_MODULE_PATH=/usr/lib64/pkcs11/azure_kms_pkcs11.so AZURE_KEYVAULT_URL=https://chewi-test.vault.azure.net/ AWS_KMS_PKCS11_DEBUG=1 sbsign --engine pkcs11 --key "pkcs11:token=flatcar-dev-cert" --cert flatcar-dev-cert.pem --output grubx64.efi.signed /efi/EFI/gentoo/grubx64.efi AWS_KMS: Debug enabled. AWS_KMS: Attempting to load config from path: /root/.config/aws-kms-pkcs11/config.json AWS_KMS: Skipping config because we couldn't open the file. AWS_KMS: Attempting to load config from path: /etc/aws-kms-pkcs11/config.json AWS_KMS: Skipping config because we couldn't open the file. AWS_KMS: No KMS key ids configured; listing all keys. AWS_KMS: Attempting to load config from path: /root/.config/aws-kms-pkcs11/azureauth.json AWS_KMS: Skipping config because we couldn't open the file. AWS_KMS: Attempting to load config from path: /etc/aws-kms-pkcs11/azureauth.json AWS_KMS: Skipping config because we couldn't open the file. AWS_KMS: Configured slots: AWS_KMS: chewi-flatcar-test-cert AWS_KMS: flatcar-dev-cert AWS_KMS: test-cert AWS_KMS: Getting public key for key flatcar-dev-cert AWS_KMS: Successfully got public key for key flatcar-dev-cert AWS_KMS: Key flatcar-dev-cert is an RSA key AWS_KMS: CKM_RSA_PKCS with SHA256 AWS_KMS: Successfully called KMS to do a signing operation. Signing Unsigned original image gentoo-vm ~/sbsign # sbverify grubx64.efi.signed --list signature 1 image signature issuers: - /emailAddress=security@flatcar.org/O=Flatcar/CN=Flatcar Secure Boot CA image signature certificates: - subject: /emailAddress=security@flatcar.org/O=Flatcar/CN=Flatcar Secure Boot CA issuer: /emailAddress=security@flatcar.org/O=Flatcar/CN=Flatcar Secure Boot CA # Download the CER file for the signing key <!-- Yet to test --> pk12util -d $PWD/flatcar-ca -o flatcar-secureboot-ca.p12 -n 'Flatcar Container Linux Secure Boot Development CA' # Export CA and Signing public keys to DER files. No password required: certutil -d $PWD/flatcar-ca -L -n "Flatcar Container Linux Secure Boot Development CA" -r > flatcar-secureboot-development-ca.cer # cd $PWD/shim-review # Update the Dockerfile env, SHIM_SIGNING_CERTIFICATE to point to flatcar-secureboot-development-ca.cer # Build the dockerfile # cp the shim*.efi --- # For production: # Turn off shell history for some commands. export HISTCONTROL=$HISTCONTROL:ignorespace # Create a temporary directory mkdir -m 0700 -p $PWD/flatcar-ca/ # Initialize a NSS database inside the directory. When prompted for a password, create a empty password i.e. press <Enter> certutil -d $PWD/flatcar-ca -N # Create CA efikeygen -d $PWD/flatcar-certs --ca --self-sign --nickname='Flatcar Container Linux Secure Boot Development CA' --common-name='CN=Flatcar Container Linux Secure Boot Development CA' # Create the Signing Keys # Generate a new certificate in the key-vault, and select the type of authority as "Certificate issued by a non-integrated CA" # Once generate it would be in Disabled mode, so select the appropriate certificate, and click "Certificate Operation" in the navbar. # Download the CSR from the pane # Download CSR from azure cp /path/to/csr-file.csr . # Convert to DER format & and sign it via root CA openssl req -in csr-file.csr -outform DER -out csr-file.der.csr certutil -C -m 2345 -i flatcar-dev-cert_d32b4c1777ea4b2f9dda7624b4208091.der.csr -o flatcar-signed.crt -c "Flatcar Secure Boot CA" -d $PWD/flatcar-ca/ -6 -5 # Convert it to the PEM for upload openssl x509 -in flatcar-signed.crt -out flatcar-cert.pem # In Azure Portal, After the request is signed, select Merge Signed Request on the Certificate Operation tab to add the signed certificate to Key Vault. ## Testing with sbsign gentoo-vm ~/sbsign # PKCS11_MODULE_PATH=/usr/lib64/pkcs11/azure_kms_pkcs11.so AZURE_KEYVAULT_URL=https://chewi-test.vault.azure.net/ AWS_KMS_PKCS11_DEBUG=1 sbsign --engine pkcs11 --key "pkcs11:token=flatcar-dev-cert" --cert flatcar-dev-cert.pem --output grubx64.efi.signed /efi/EFI/gentoo/grubx64.efi AWS_KMS: Debug enabled. AWS_KMS: Attempting to load config from path: /root/.config/aws-kms-pkcs11/config.json AWS_KMS: Skipping config because we couldn't open the file. AWS_KMS: Attempting to load config from path: /etc/aws-kms-pkcs11/config.json AWS_KMS: Skipping config because we couldn't open the file. AWS_KMS: No KMS key ids configured; listing all keys. AWS_KMS: Attempting to load config from path: /root/.config/aws-kms-pkcs11/azureauth.json AWS_KMS: Skipping config because we couldn't open the file. AWS_KMS: Attempting to load config from path: /etc/aws-kms-pkcs11/azureauth.json AWS_KMS: Skipping config because we couldn't open the file. AWS_KMS: Configured slots: AWS_KMS: chewi-flatcar-test-cert AWS_KMS: flatcar-dev-cert AWS_KMS: test-cert AWS_KMS: Getting public key for key flatcar-dev-cert AWS_KMS: Successfully got public key for key flatcar-dev-cert AWS_KMS: Key flatcar-dev-cert is an RSA key AWS_KMS: CKM_RSA_PKCS with SHA256 AWS_KMS: Successfully called KMS to do a signing operation. Signing Unsigned original image gentoo-vm ~/sbsign # sbverify grubx64.efi.signed --list signature 1 image signature issuers: - /emailAddress=security@flatcar.org/O=Flatcar/CN=Flatcar Secure Boot CA image signature certificates: - subject: /emailAddress=security@flatcar.org/O=Flatcar/CN=Flatcar Secure Boot CA issuer: /emailAddress=security@flatcar.org/O=Flatcar/CN=Flatcar Secure Boot CA # Download the CER file for the signing key <!-- Yet to test --> pk12util -d $PWD/flatcar-ca -o flatcar-secureboot-ca.p12 -n 'Flatcar Container Linux Secure Boot Development CA' # Export CA and Signing public keys to DER files. No password required: certutil -d $PWD/flatcar-ca -L -n "Flatcar Container Linux Secure Boot Development CA" -r > flatcar-secureboot-development-ca.cer # cd $PWD/shim-review # Update the Dockerfile env, SHIM_SIGNING_CERTIFICATE to point to flatcar-secureboot-development-ca.cer # Build the dockerfile # cp the shim*.efi ``` ## Guidelines for the shim signing ### Implmentation of the questions ### UEFI Signing Requirements Please refer to the document: https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916 The tasks, questions, or comments from the document is listed against the respective number. ``` UEFI signing is a service provided by the Windows Hardware Dev Center dashboard by which developers submit UEFI firmware binaries targeted to x86, x86-64, or ARM computers. After these binaries are approved through manual review, the owners can install them on PCs that have secure boot enabled with the Microsoft 3rd Party UEFI CA permitted. While Microsoft reserves the right to sign or not sign submissions at its discretion, you should adhere to these requirements. Doing so will help you achieve faster turnaround times for getting a submission signed and help avoid revocation. Microsoft may conduct follow-up reviews, including but not limited to questionnaires, package testing, and other security testing of these requirements before signing. The following list contains the latest requirements for the UEFI signing process. These requirements are to ensure the security promise of secure boot, and to help expedite the turnaround of signing submissions. 1. UEFI submissions require an EV certificate and an Azure Active Directory (AAD) account. 2. Only production quality code (for example, “release to manufacturing” code, rather than test or debug modules) that will be released to customers (no internal-only code or tools) are eligible for UEFI signing. For internal-use code, you should add your own key to the Secure Boot database UEFI variable or turn off Secure Boot during development and testing. 3. Microsoft UEFI CA signs only those products that are for public availability and are needed for inter-operability across all UEFI Secure Boot supported devices. If a product is specific to a particular OEM or organization and is not available externally, you should sign it with your private key and add the certificate to Secure Boot database. 4. Code submitted for UEFI signing must not be subject to GPLv3 or any license that purports to give someone the right to demand authorization keys to be able to install modified forms of the code on a device. Code that is subject to such a license that has already been signed might have that signature revoked. For example, GRUB 2 is licensed under GPLv3 and will not be signed. 5. If there’s a known malware vector related to code that uses certain techniques, that code will not be signed and is subject to revocation. For example, the use of versions of GRUB that aren’t Secure Boot enlightened will not be signed. 6. If there are known security vulnerabilities in your submission code, the submission will not be signed, even if your functionality doesn’t expose that code. For example, the latest known secure versions of OpenSSL are 0.9.8za and 1.0.1h, so if your submission contains earlier versions that contain known vulnerabilities, the submission will not be signed. 7. You must test your product, following the Pre-Submission testing document (for UEFI Submissions), before submitting for signing. 8. Microsoft will not sign EFI submissions that use EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER. Instead, we recommend transitioning to EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER. This prevents unnecessary use of runtime EFI drivers. 9. Use of EFI Byte Code (EBC): Microsoft will not sign EFI submissions that are EBC-based submissions. 10. If your submission is a DISK encryption or a File/Volume based encryption, then you MUST make sure that you either don’t encrypt the EFI system partition or if you do encrypt, be sure to decrypt it and make it available by the time Windows is ready to boot. 11. If your submission is comprised of many different EFI modules, multiple DXE drivers, and multiple boot applications, Microsoft may request that you consolidate your EFI files into a minimal format. An example may be a single boot application per architecture, and a consolidation of DXE drivers into one binary. 12. If your submission is a SHIM (handing off execution to another bootloader), then you must first submit to the SHIM review board and be approved before a submission will be signed. This review board will check to ensure the following: A. Code signing keys must be backed up, stored, and recovered only by personnel in trusted roles, using at least dual-factor authorization in a physically secured environment. i. The private key must be protected with a hardware cryptography module. This includes but is not limited to HSMs, smart cards, smart card–like USB tokens, and TPMs. ii. The operating environment must achieve a level of security at least equal to FIPS 140-2 Level 2. iii. If embedded certificates are EV certificates, you should meet all of the above requirements. We recommend that you use an EV certificate because this will speed up UEFI CA signing turnaround. B. Submitter must design and implement a strong revocation mechanism for everything the shim loads, directly and subsequently. C. If you lose keys or abuse the use of a key, or if a key is leaked, any submission relying on that key will be revoked. D. Some shims are known to present weaknesses into the SecureBoot system. For a faster signing turnaround, we recommend that you use source code of 0.8 or higher from shim - GitHub branch. 13 If your submission contains iPXE functionality, then additional security steps are required. Previously, Microsoft has completed an in depth security review of 2Pint’s iPXE branch. In order for new submissions with iPXE to be signed, they must complete the following steps: A. Pull and merge from 2Pint's commit: http://git.ipxe.org/ipxe.git/commitdiff/7428ab7 B. Get a security review from a verified vendor. Refer vendor to the iPXE Security Assurance Review blog post. Emphasis of the review should be on: i. NFS functionality being removed ii. Wireless functionality being removed iii. Non-UEFI loaders are not included iv. Ensuring all known reported security problems are fixed (identified in the iPXE Security Assurance Review blog post). C. Share the specific commits that are made to the project, allowing Microsoft to ensure the expected changes are made. For questions about the UEFI Signing process, contact uefisign@microsoft.com ``` - [ ] UEFI submissions require an EV certificate and an Azure Active Directory (AAD) account. * EV certificate is not mandatory - [x] Only production images should be submitted for signed review, developer images needs to have our own key submitted to the Secure Boot database. We are already sorted with this as only our developer images are signed. - [x] Currently, We are on the GRUB 2.06. Ideally upgrade to 2.12, also identify any CVEs in the boot stack. - [ ] Identify the CVEs in the bootstack. Refer to point 6. - [ ] [Check if required] Submissions should not use EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER and should use EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER * T. Check on what these two means, and how this affects Flatcar submission - [ ] Generate the keys in FIPS 140-2 Level 2 HSMs - [ ] Design a revocation mechanism. Add to release process on how to add old shim hash to DBX. We also need to think of cycling the keys. ## Shim Submitting Guidelines Please refer to the document: https://github.com/rhboot/shim-review/blob/main/docs/submitting.md ## 0. Do you need and can you support a signed shim build? ``` These may sound like odd questions! Are you 100% sure that you **need** a shim build including your vendor key? Not everybody needs this; for small deployments it's often possible (and easier!) to add public keys directly into firmware on the machines involved. If you're a hardware vendor and you have control over the firmware on machines that you ship, install your keys into the other keyrings by preference. If you expect your software to be directly used on a larger number of machines from multiple hardware vendors, then shim is a more reasonable path to follow. **Before** you start working with shim, you should also plan for how to support your build in the long run. As a minimum, reviewers will need two sets of contact details for people who will be responsible for it going forwards. We may need to get in touch as and when security issues appear in future. Depending on the nature of such issues, you may need to revoke signatures and keys and/or build a new version of shim with new patches included. If you are not sure you will be able to commit to this, then shim may not be a good option for you. ``` - [ ] Find two PoC for the task, who will be contacted for when a issue occures. They will be validated via GPG email. A question for the same exists in the shim READMD.md ## 1. Sign up with Microsoft ``` If you're sure you need your own shim binary signed by Microsoft, first go and create an account etc. with them. Check [Microsoft's signing policies](https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916) for all their specific requirements. ``` - [ ] Sign up for https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916 ## 2. Build and test shim ``` Start with the current stable release of shim, and check for any further recommended patches that you might need. Configure and build, Check that you understand how to handle various things: embedding keys, revoking the ability to load further binaries (both by signature and by checksum), etc. **Test** your shim build as much as you can - this is important. Early testing is possible in VMs, and this is recommended as it's much quicker and easier than fighting with real hardware. Of course, you will **also** want to test that things work well on a range of real-world hardware before you submit. ``` - [ ] Need to be tested against multiple hardwares (Add Azure, QEMU in the pipeline) ## 3. Prepare for submission for review ``` Once you're happy that your build works, it's time to prepare for submitting it. This may seem long-winded, but the better you make your submission the easier it will be for reviewers to mark your build as accepted. ``` ### 3.1 SBAT data ``` **SBAT** is ``Secure Boot Advanced Targeting``. It's a method to efficiently handle revocation of old insecure Secure Boot binaries, introduced in shim for the 15.3 release. The [SBAT spec](https://github.com/rhboot/shim/blob/main/SBAT.md) and [SBAT examples](https://github.com/rhboot/shim/blob/main/SBAT.example.md) documents have a lot more information about how it works, and what's needed. If you are generating Secure Boot binaries (i.e. shim and the programs it will run), you will need to add SBAT data to all of them: * Pick a clear short **vendor** name that will be unique. Don't use a name that's too short or too long! If the name is too short, it's more likely to clash with others. * Work out the right **component_generation** (see the docs) * If you are deriving your source from another vendor's build, **also** include their SBAT vendor data. This helps the community track the provenance of changes (and bugs), and allows us to efficiently deal with publishing revocations in the future. The shim build system provides an easy way to attach vendor SBAT data provided in CSV form. If you're not sure on any of this, please ask for advice before submission! ``` - [ ] #TODO SBAT Data - Will need to write a document to help managing the data ### 3.2 Certificates and keys and revocations ``` You'll need to embed certificate data into your shim build, of course - this is the purpose of shim! You can include multiple certificates if desired. **NOTE:** The certificate(s) must be encoded using **DER** format, **not** PEM. You may also need to include lists of revocations. For example, you may need to revoke old binaries or signatures after a security hole has been discovered. It's possible to revoke a certificate (and therefore all signatures from it), and also to directly disable loading individual binaries by checksum. There are strong recommendations on the types of certificates that should be used in shim, and also on how keys should be managed for security. See the 12th bullet in [Microsoft UEFI Signing Requirements](https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916) for tips on this, and also some sugested schems for key and certificate management. ``` - [ ] Draft a revocation document stating the process of cycling the keys, and authorizations. ### 3.3 Reproducible build ``` Reviewers will need to validate that they can reproduce your shim build. This is critically important - nobody will trust and sign a binary that is not reproducible. The **best** recommendation here is for you to create a Dockerfile that will do the right thing to reproduce your build. This is **not** mandatory, but not following the normal path here makes it harder for reviewers. If you are a Linux distribution developer, please try to have this docker image set up your normal build environment and build just like you would for your distribution; it'll make it easier to compare results that way. **Be careful** with the choice of compiler etc. here also - if you're tracking an "unstable" or "rolling" distribution then a different compiler version may cause your binary to not match the binary that a reviewer builds a week later. If you are a tool developer needing a signed shim, pick a stable base image to use for your Dockerfile and make it easy for reviewers. If you absolutely **cannot** use a container image for some reason, find another similar way to proceed and write clear easy docs for the reviewer to follow. In all cases, make things as straightforward as possible for your reviewer and they'll be much happier to help you! * Please have a docker build use a standard setup: ``docker build .`` is easy for reviewers. If you need a wrapper script to do things, call that from the Dockerfile. * Please have your build script print the checksum(s) of your shim binaries, both the newly-built shim and the binary you're including in your submission. ``` - [ ] Write a Dockerfile, along with the steps to be submitted when updated the shim-review README.md ### 3.4 Shim sources and patches ``` Again, make sure that you're using the current stable release of shim. If you're not, reviewers will simply reject your submission and ask you to start again. Check that you have picked up any upstream patches recommended for your use cases. To help with this, there should be tracking issues pinned in the [shim-review](https://github.com/rhboot/shim-review/issues) issues list which includes details of current patches recommended for inclusion. If you add any patches from upstream like this, again **please** make it easy for reviewers to verify what the patches are. ``git format-patch`` is your friend here - patch file names, commit hashes and commit messages will all help the reviewer here. If you have your **own** patches to shim, these will of course take more time and effort for review. In all cases, please try to open upstream PRs for them and/or discuss them on the EFI mailing list first! If you have non-trivial changes, make sure that you explain exactly what your changes are and why you need them. Shim is security-critical and reviewers will need to understand your changes and verify that they do not cause security regressions. Similarly, shim is normally used to load GRUB or systemd-boot as the system bootloader. if you're doing something different, this will need deeper review. Please make it as easy as possible for reviewers to understand what you're doing (and why!) if you want them to accept your shim for signing. ``` ### 3.5 Sources and patches for other components ``` Reviewers will expect to be able to inspect your GRUB or systemd-boot sources to validate the state of Secure Boot patches in particular, and will normally also ask about patches to other system components like Linux and fwupd. We need to consider the security of the entire boot chain here - shim is just the first step. ``` - [ ] Draft a writeup explaining the GRUB2 patches. #### Action Items - [ ] Find two PoC for the task, who will be contacted for when a issue occures. They will be validated via GPG email. A question for the same exists in the shim READMD.md - [ ] Sign up for https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916 - [ ] Need to be tested against multiple hardwares (Add Azure, QEMU in the pipeline) - [ ] #TODO SBAT Data - Will need to write a document to help managing the data - [ ] Draft a revocation document stating the process of cycling the keys, and authorizations. - [ ] Write a Dockerfile, along with the steps to be submitted when updated the shim-review README.md - [ ] Draft a writeup explaining the GRUB2 patches. ### Shim review submission task list - [x] A. Fork the rhboot/shim-review repo - https://github.com/flatcar/shim-review - [ ] B. completed README.md file with the necessary information - [x] 1. What organization or people are asking to have this signed? ``` Flatcar Container Linux ```` - [x] 2. What product or service is this for? ``` Flatcar Container Linux is a fully open source, minimal-footprint, secure by default and always up-to-date Linux distribution for running containers at scale. ``` - [ ] 3. What's the justification that this really does need to be signed for the whole world to be able to boot it? ``` Flatcar Container Linux is a fully open source, minimal-footprint, secure by default and always up-to-date Linux distribution for running containers at scale. Flatcar Container Linux supports an array of cloud providers, including Microsoft Azure, Amazon Web Services, Google Cloud Platform, and others. Flatcar users heavily use Flatcar for their container workloads and deployments, and as security is one of pillars of the OS, we would like to add Secure Boot support images, to aid users their secure supply chain. ``` - [ ] 4. Why are you unable to reuse shim from another distro that is already signed? ``` Flatcar Container Linux manages it's own build system and pipeline to maintain the images. For Secure Boot pipeline, we would be signing our built Grub, Linux - so we would be unable to use signed shim of another distribution. ``` - [ ] 5. Who is the primary contact for security updates, etc.? An authorized reviewer will initiate contact verification by sending each security contact a PGP-encrypted email containing random words. You will be asked to post the contents of these mails in your shim-review issue to prove ownership of the email addresses and PGP keys. ``` Name: Sayan Chowdhury Position: Senior Software Engineer Email address: schowdhury@microsoft.com PGP key fingerprint: 0F16E841E517225C7D13AB3CB02399319CD05C8B ``` - [ ] 6. Who is the secondary contact for security updates, etc.? ``` Name: Thilo Fromm Position: Princpal SWE Manager Email address: thilofromm@microsoft.com PGP key fingerprint: 77CCD95931393677344E83A481CE0776EF50B157 ``` - [ ] 7. Were these binaries created from the 15.8 shim release tar? ``` Yes, These binaries created from the 15.8 release tar. Please refer to the ebuild for source: https://github.com/flatcar/scripts/blob/main/sdk_container/src/third_party/coreos-overlay/sys-boot/shim/shim-15.8-r1.ebuild#L9 ``` - [ ] 8. URL for a repo that contains the exact code which was built to result in your binary: ``` The repo is here: https://github.com/flatcar/scripts/ The shim ebuild can be found here: https://github.com/flatcar/scripts/blob/main/sdk_container/src/third_party/coreos-overlay/sys-boot/shim/shim-15.8-r1.ebuild We carry a patch as because the bundled gnu-efi build is implemented in a buggy way that can break when built in parallel. We've hit this in the nightly sdk build. The patch included fixes this. We have also submitted a PR upstream [rhboot/shim#643](https://github.com/rhboot/shim/pull/643). ``` - [ ] 9. What patches are being applied and why: ``` We carry a patch as because the bundled gnu-efi build is implemented in a buggy way that can break when built in parallel. We've hit this in the nightly sdk build. The patch included fixes this. We have also submitted a PR upstream [rhboot/shim#643](https://github.com/rhboot/shim/pull/643). ``` - [ ] 10. Do you have the NX bit set in your shim? If so, is your entire boot stack NX-compatible and what testing have you done to ensure such compatibility? ``` No, our boot stack is not NX bit compatible. ``` - [ ] 11. What exact implementation of Secure Boot in GRUB2 do you have? (Either Upstream GRUB2 shim_lock verifier or Downstream RHEL/Fedora/Debian/Canonical-like implementation) - [X] 12. Do you have fixes for all the following GRUB2 CVEs applied? Please refer to the list of CVEs here -> https://github.com/rhboot/shim-review#do-you-have-fixes-for-all-the-following-grub2-cves-applied ``` Yes, vanilla GRUB 2.12 is clean as of 2024/09/13. ``` - [X] 13. If shim is loading GRUB2 bootloader, and if these fixes have been applied, is the upstream global SBAT generation in your GRUB2 binary set to 4? ``` Yes. https://github.com/flatcar/scripts/blob/main/sdk_container/src/third_party/coreos-overlay/coreos/config/env/sys-boot/grub#L6 The GRUB SBAT Generation is set to 4. ``` - [X] 14. Were old shims hashes provided to Microsoft for verification and to be added to future DBX updates? ``` This is our first application, and We don't have a signed shim from Microsoft yet. ``` - [ ] 15. Does your new chain of trust disallow booting old GRUB2 builds affected by the CVEs? ``` This is our first application, and We don't have a signed shim from Microsoft yet. ``` - [ ] 16. If your boot chain of trust includes a Linux kernel: 1. Is upstream commit 1957a85b0032a81e6482ca4aab883643b8dae06e "efi: Restrict efivar_ssdt_load when the kernel is locked down" applied? 2. Is upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 "ACPI: configfs: Disallow loading ACPI tables when locked down" applied? 3. Is upstream commit eadb2f47a3ced5c64b23b90fd2a3463f63726066 "lockdown: also lock down previous kgdb use" applied? ``` Yes, we include all mentioned upstream commits. ``` - [ ] 17. Do you build your signed kernel with additional local patches? What do they do? ``` Our Linux kernel is based on 6.6 tree, and we carry three local patches - [PATCH 1] We modify the Makefile to derive the relative path for `srctree` from the current directory (CURDIR) when building out of the source tree with the motivation which enables relocating the source and build trees to different roots, as long as they remain reachable relative to one another. - [PATCH 2] We drop the pahole flags - [PATCH 3] We revert the Linux [commit](https://github.com/gregkh/linux/commit/768171d7ebbce005210e1cf8456f043304805c15) as it is required for storing the dm-verity hash - [PATCH 4] Add an EFI_SECURE_BOOT flag to indicate secure boot mode - [PATCH 5] Lockdown the kernel when booted in Secure Boot mode - [PATCH 6] Disable phram/slram to preserve the kernel's integrity when it is locked down. - [PATCH 7] Add a kernel configuration option to lock down the kernel, to restrict userspace's ability to modify the running kernel when UEFI Secure Boot is enabled for ARM64 ``` - [ ] 18. Do you use an ephemeral key for signing kernel modules? If not, please describe how you ensure that one kernel build does not load modules built for another kernel. - [ ] 19. If you use vendor_db functionality of providing multiple certificates and/or hashes please briefly describe your certificate setup. If there are allow-listed hashes please provide exact binaries for which hashes are created via file sharing service, available in public with anonymous access for verification. ``` We don't use the vendor_db functionality, nor do we include any allow-listed hashes. ``` - [X] 20. If you are re-using the CA certificate from your last shim binary, you will need to add the hashes of the previous GRUB2 binaries exposed to the CVEs mentioned earlier to vendor_dbx in shim. Please describe your strategy. ``` This is our first submission for shim signing. ``` - [ ] 21. Is the Dockerfile in your repository the recipe for reproducing the building of your shim binary? ``` Please refer to the [Dockerfile](https://github.com/flatcar/shim-review/blob/main/Dockerfile) ``` - [ ] 22. Which files in this repo are the logs for your build? ``` Please refer to the [build.log](https://github.com/flatcar/shim-review/blob/main/build.log) ``` - [X] 23. What changes were made in the distro's secure boot chain since your SHIM was last signed? ``` This is our first submission for shim signing. ``` - [ ] 24. What is the SHA256 hash of your final shim binary? - [ ] 25. How do you manage and protect the keys used in your shim? - [ ] 26. Do you use EV certificates as embedded certificates in the shim? ``` No ``` - [ ] 27. Do you add a vendor-specific SBAT entry to the SBAT section in each binary that supports SBAT metadata ( GRUB2, fwupd, fwupdate, systemd-boot, systemd-stub, shim + all child shim binaries )? Please provide the exact SBAT entries for all binaries you are booting directly through shim.- ``` sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim shim.flatcar,1,Flatcar Container Linux,shim,15.8-r1,security@flatcar-linux.org sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md grub,4,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/ grub.flatcar,1,Flatcar,grub2,2.06-r10,https://github.com/flatcar/flatcar We do not provide with fwupd, fwupdate, and systemd-boot. ``` - [ ] 28. If shim is loading GRUB2 bootloader, which modules are built into your signed GRUB2 image? ``` The GRUB2 standard modules are built into our image are: normal, search, test, fat, part_gpt, gzio, search_part_label, terminal, configfile, memdisk, tar, echo, read, btrfs The GRUB2 non-standard modules by Flatcar that are built into the image are: search_part_label, search_fs_uuid, gptprio ``` - [X] 29. If you are using systemd-boot on arm64 or riscv, is the fix for unverified Devicetree Blob loading included? ``` We don't use systemd-boot. ``` - [ ] 30. What is the origin and full version number of your bootloader (GRUB2 or systemd-boot or other)? - [ ] 31. If your shim launches any other components apart from your bootloader, please provide further details on what is launched. ``` Shim loads no components other than GRUB2 ``` - [ ] 32. If your GRUB2 or systemd-boot launches any other binaries that are not the Linux kernel in SecureBoot mode, please provide further details on what is launched and how it enforces Secureboot lockdown. ``` N/A ``` - [ ] 33. How do the launched components prevent execution of unauthenticated code? ``` N/A ``` - [ ] 34. Does your shim load any loaders that support loading unsigned kernels (e.g. certain GRUB2 configurations)? ``` No. ``` - [ ] 35. What kernel are you using? Which patches and configuration does it include to enforce Secure Boot? ``` Our Kernel is based on 6.6 LTS kernel. We have GH actions, which regularly monitors for new maintenance releases, and the patches are applied soon as soon as the our CI is green. kernel 6.6.x ebuild https://github.com/flatcar/scripts/blob/main/sdk_container/src/third_party/coreos-overlay/sys-kernel/coreos-kernel/coreos-kernel-6.6.51.ebuild ``` - [ ] 36. What contributions have you made to help us review the applications of other applicants? ``` No, we haven't done any contributions yet but we do plan to contribute in the future before our next shim-review ``` - [ ] 37. Add any additional information you think we may need to validate this shim signing application. ``` None ``` - [ ] C. Produce the shim.efi to be signed - [ ] D. Public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE) - [ ] E. Binaries, for which hashes are added to vendor_db ( if you use vendor_db and have hashes allow-listed ) - [ ] F. any extra patches to shim via your own git tree or as files - [ ] G. Build logs from our server - [ ] H. A Dockerfile to reproduce the build of the provided shim EFI binaries