This repo is for review of requests for signing shim. To create a request for review:
- clone this repo
- edit the template below
- add the shim.efi to be signed
- add build logs
- add any additional binaries/certificates/SHA256 hashes that may be needed
- commit all of that
- tag it with a tag of the form "myorg-shim-arch-YYYYMMDD"
- push that to github
- file an issue at https://github.com/rhboot/shim-review/issues with a link to your tag
- approval is ready when the "accepted" label is added to your issue
Note that we really only have experience with using GRUB2 or systemd-boot on Linux, so asking us to endorse anything else for signing is going to require some convincing on your part.
Check the docs directory in this repo for guidance on submission and getting your shim signed.
Here's the template:
We are the Miray Software AG, producers of microkernel OS "Symobi" and the widely known Stand-Alone-Tools "HDClone" and "HDShredder" as well as other hardware related tools, running without an installed operating system. https://www.miray-software.com/
The product is a Self-Booting system (typically from a USB flash drive or a CD, containing one of our Stand-Alone-Tools, based on either our own microkernel OS "Symobi" or a Linux kernel with our application framework on top. A similar version, which runs as a normal Windows application, also exists, but isn’t actually considered to be "Stand-Alone", as it requires an existing Windows installation and is limited in several aspects that require direct hardware access.
We have used a Microsoft SecureBoot signed Shim since 2014 and the focus and requirements of our products have not changed since then.
What's the justification that this really does need to be signed for the whole world to be able to boot it?
We make software tools for Data Cloning, Backup/Recovery and Secure Deletion, as well as other specialized tools for computer technicians, companies and industrial use. Our tools are well known and used worldwide in more than 160 countries. Many of the tasks our software performs requires direct hardware acces and is usually not possible to perform under a Windows environment. Especially restoring system backups, deployment of master images, data rescue and forensic imaging requires our software to boot directly on SecureBoot systems.
We use Grub to boot our own operating system. We also provide our own Grub and Linux kernel builds.
The security contacts need to be verified before the shim can be accepted. For subsequent requests, contact verification is only necessary if the security contacts or their PGP keys have changed since the last successful verification.
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: Alexander Roalter
- Position: Head of Development
- Email address: [email protected]
- PGP key fingerprint: 3EE6 23F1 9DEC 8A00 0773 2ABC FC8B 2517 5C00 B621
(Key should be signed by the other security contacts, pushed to a keyserver like keyserver.ubuntu.com, and preferably have signatures that are reasonably well known in the Linux community.)
Key included as ar.asc in this submission and uploaded to keyserver.ubuntu.com
- Name: Thomas Frauendorfer
- Position: Shim, Grub & Linux Buildroot Development
- Email address: [email protected]
- PGP key fingerprint: 1D14 5EC6 E6FA 6A48 571F A8CE 8837 9A48 8016 CE28
(Key should be signed by the other security contacts, pushed to a keyserver like keyserver.ubuntu.com, and preferably have signatures that are reasonably well known in the Linux community.)
Key included as th.asc in this submission and uploaded to keyserver.ubuntu.com
Please create your shim binaries starting with the 15.8 shim release tar file: https://github.com/rhboot/shim/releases/download/15.8/shim-15.8.tar.bz2
This matches https://github.com/rhboot/shim/releases/tag/15.8 and contains the appropriate gnu-efi source.
Yes
https://github.com/rhboot/shim/tree/15.8
The applied patches are in subdirectory shim-patches of this submission
- 0001-Disable-Command-line-handling.patch
Command line handling caused problems in earlier shim versions. We already disabled the command line handling there so for now we keep doing that
- 0002-Don-t-try-to-load-fallback-or-mokmanager.patch
Remove code that tries to start fallback or MokManager as we neither ship nor use them
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?
See https://techcommunity.microsoft.com/t5/hardware-dev-center/nx-exception-for-shim-community/ba-p/3976522 for more details on the signing of shim without NX bit.
NX bit is not set
If shim is loading GRUB2 bootloader what exact implementation of Secureboot in GRUB2 do you have? (Either Upstream GRUB2 shim_lock verifier or Downstream RHEL/Fedora/Debian/Canonical-like implementation)
We use upstream GRUB2 shim_lock verifier.
If shim is loading GRUB2 bootloader and your previously released shim booted a version of GRUB2 affected by any of the CVEs in the July 2020, the March 2021, the June 7th 2022, the November 15th 2022, or 3rd of October 2023 GRUB2 CVE list, have fixes for all these CVEs been applied?
- 2020 July - BootHole
- Details: https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00034.html
- CVE-2020-10713
- CVE-2020-14308
- CVE-2020-14309
- CVE-2020-14310
- CVE-2020-14311
- CVE-2020-15705
- CVE-2020-15706
- CVE-2020-15707
- March 2021
- Details: https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00007.html
- CVE-2020-14372
- CVE-2020-25632
- CVE-2020-25647
- CVE-2020-27749
- CVE-2020-27779
- CVE-2021-3418 (if you are shipping the shim_lock module)
- CVE-2021-20225
- CVE-2021-20233
- June 2022
- Details: https://lists.gnu.org/archive/html/grub-devel/2022-06/msg00035.html, SBAT increase to 2
- CVE-2021-3695
- CVE-2021-3696
- CVE-2021-3697
- CVE-2022-28733
- CVE-2022-28734
- CVE-2022-28735
- CVE-2022-28736
- CVE-2022-28737
- November 2022
- Details: https://lists.gnu.org/archive/html/grub-devel/2022-11/msg00059.html, SBAT increase to 3
- CVE-2022-2601
- CVE-2022-3775
- October 2023 - NTFS vulnerabilities
- Details: https://lists.gnu.org/archive/html/grub-devel/2023-10/msg00028.html, SBAT increase to 4
- CVE-2023-4693
- CVE-2023-4692
Yes, we use the fedora-39 (2.06-104.fc39) from Oct 3, 2023 as base which includes the patches for CVEs up to 2022 We added the patches for the October 2023 CVEs on top of the fedora tree
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?
The entry should look similar to: grub,4,Free Software Foundation,grub,GRUB_UPSTREAM_VERSION,https://www.gnu.org/software/grub/
Yes
hashes for shims without SBAT support have been provided.
GRUB2 is only loaded directly by SHIM, which checks against SBAT entries.
- GRUB2 non-EFI chainloader module is disabled
- GRUB2 EFI chainloader respects the chain of trust
- Linux kexec is disabled
- Symobi does not support loading other kernels.
Is upstream commit 1957a85b0032a81e6482ca4aab883643b8dae06e "efi: Restrict efivar_ssdt_load when the kernel is locked down" applied?
Is upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 "ACPI: configfs: Disallow loading ACPI tables when locked down" applied?
Is upstream commit eadb2f47a3ced5c64b23b90fd2a3463f63726066 "lockdown: also lock down previous kgdb use" applied?
Yes, We use linux lts kernel 6.1.15 which includes all these patches
1957a85b0032a81e6482ca4aab883643b8dae06e is included since upstream Linux version 5.4.0 75b0cea7bf307f362057cc778efe89af4c615354 is included since upstream Linux version 5.8.0 eadb2f47a3ced5c64b23b90fd2a3463f63726066 is included since upstream Linux version 5.19.0
We have not signed any Linux kernels with kgdb support, so our older Linux kernels are also not affected by eadb2f47a3ced5c64b23b90fd2a3463f63726066
While not explicitly asked for yet: 543ce63b664e2c2f9533d089a4664b559c3e6b5b "lockdown: Fix kexec lockdown bypass with ima policy" is also included since upstream Linux version 5.19.0 We also have not signed any Linux kernels with kexec support, so our older Linux kernels are also not affected by 543ce63b664e2c2f9533d089a4664b559c3e6b5b
We apply the SecureBoot lockdown patches from Debian
We silence bootup log messages regarding SecureBoot status We disable hashing of pointers in debug messages We add an additional pci_device_id entry to ahci
If not, please describe how you ensure that one kernel build does not load modules built for another kernel.
Yes, we discard the autogenerated module signing keys after module_install
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.
Not used, no binaries allow-listed
If you are re-using a previously used (CA) certificate, you will need to add the hashes of the previous GRUB2 binaries exposed to the CVEs to vendor_dbx in shim in order to prevent GRUB2 from being able to chainload those older GRUB2 binaries. If you are changing to a new (CA) certificate, this does not apply.
We use a new certificate
What OS and toolchain must we use to reproduce this build? Include where to find it, etc. We're going to try to reproduce your build as closely as possible to verify that it's really a build of the source tree you tell us it is, so these need to be fairly thorough. At the very least include the specific versions of gcc, binutils, and gnu-efi which were used, and where to find those binaries.
If the shim binaries can't be reproduced using the provided Dockerfile, please explain why that's the case and what the differences would be.
We use Ubuntu 22.04 on x86_64 as build environment for shim.
You can use the Dockerfile to verify the build.
This should include logs for creating the buildroots, applying patches, doing the build, creating the archives, etc.
'build.x64.log' holds the complete build run, starting with cleanup of old files, checkout, build and packaging the built file into a .cab file for x86_64.
'build.aa64.log' holds the complete build run, starting with cleanup of old files, checkout, build and packaging the built file into a .cab file for arm64.
For example, signing new kernel's variants, UKI, systemd-boot, new certs, new CA, etc..
Last accepted review: rhboot#247
Changes for Shim:
- Updated to shim 15.8
- Replaced certificate after the old certificate expired
- dropped vendor_dbx file
- SBAT generation number for shim.miray dropped back to 1 (as requested in review #355)
Changes for Grub:
- Changed base to fedora-39 and rebased our own patches on top of that branch
- Use EFI chainloader instead of Multiboot for Symobi when SecureBoot is active
- Disable Multiboot loader when SecureBoot is active
- SBAT generation number for grub.miray dropped back to 1 (as requested in review #355)
Changes for own operating system Symobi:
- Added support for EFI boot protocol / EFI chainloader
- Added NX support
- Added Sbat section
shim_mirayx64.efi: f380dc1d382483c3229305c1fec4b57395edf04f515c439445aa09cc9b3feb94
shim_mirayaa64.efi: 3bab2c22c4c658be2fe63b528485b1f19c256d23e5585b3154e403db2e8683ef
Keys are stored in a hardware token. Access to the token is restricted.
Yes, EV certificate issued by DigiCert.
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 exact SBAT entries for all SBAT binaries you are booting or planning to boot directly through shim.
Where your code is only slightly modified from an upstream vendor's, please also preserve their SBAT entries to simplify revocation.
If you are using a downstream implementation of GRUB2 or systemd-boot (e.g. from Fedora or Debian), please preserve the SBAT entry from those distributions and only append your own. More information on how SBAT works can be found here.
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.miray,1,Miray Software,shim,miray-15.8,https://www.miray-software.com
Grub: 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.miray,1,Miray Software,grub2,sysload_2.8.4,https://github.com/MiraySoftware/grub2
Symobi: sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md symobi,1,Miray Software GbR,Symobi,1.9.0,https://www.miray-software.com/ symobi.miray,1,Miray Software AG,Symobi,1.9.0,https://www.miray-software.com/
acpi
archelp
bitmap
bitmap_scale
boot
bufio
chain
configfile
crypto
datetime
disk
efi_gop
efinet
exfat
extcmd
fat
font
fshelp
gcry_crc
gfxmenu
gfxterm
gzio
hexdump
iso9660
linux
loadenv
ls
memdisk
minicmd
mmap
multiboot2
net
normal
ntfs
part_gpt
part_msdos
png
priority_queue
probe
procfs
relocator
search
search_fs_file
search_fs_uuid
search_label
smbios
tar
terminal
terminfo
test
tftp
trig
true
video
video_colors
video_fb
videoinfo
xzio
cpuid
efi_uga
multiboot
random
fdt
boothelper
boothelper_net
lzmaio
miray
miray_boottime
miray_gfx
miray_memobj
miray_proc_videoinfo
zzio
If you are using systemd-boot on arm64 or riscv, is the fix for unverified Devicetree Blob loading included?
Not used
sysload_2.8.3 Based on GRUB2 from fedora-39 branch from Oct 4, 2023. That is the source for fedora release grub2-2.06-104.fc39
Additional Patches on top of that:
- Ntfs OOB fixes from grub main (CVE-2023-4692, CVE-2023-4693, non-cve fixes)
- Secureboot adjustments to use upstream grub lockdown checks instead of secureboot checks
- Update to lzma code and custom lzma decompression filter
- custom menu code
- Patches to support multiboot on arm
The source tree is available from https://github.com/MiraySoftware/grub2/tree/sysload_2_8
Shim is only used to launch the GRUB based bootloader.
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.
We launch our own microkernel operating system Symobi through the multiboot or multiboot2 protocol.
- Symobi:
- Symobi is a microkernel operating system with a minimal kernel. Hardware drivers are loaded as separate processes from a core file system. The kernel validates the core file system against a SHA2 hash which is embedded in the signed kernel. Only drivers stored in that core file system are allowed to access hardware.
- MMIO, I/O space and DMA access is only allowed for drivers in the core file system.
- Symobi does NOT support changing or writing to ACPI data.
- Manual hardware configuration is NOT supported. All hardware configuration is done through PCI and ACPI information
- Launching other kernels is NOT supported.
- Access to kernel memory is restricted to the kernel itself.
- Access to MSRs (Model specific register) is restricted to the kernel.
- Symobi does NOT support swap files or hibernation.
- IOMMU is used if available.
- When started through Multiboot:
- EFI Bootservices are disabled by GRUB before the operating system is started
- When started through Chainloader / EFI entry point
- EFI Bootservices are disabled by kernel early in kernel init code
- NX support is enabled / used
Side by side comparison against Coverage section of https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html
The whole section is in blockquotes Information about Symobi is added like this
parts are taken from the Coverage section are quoted separately
Overview: The Symobi OS microkernel (Sphere) does not load any external components into kernel memory. In order to start the rest of the system, it needs to start user mode code (basic drivers and services), which is located in the "core file system". It is located in one blob/file, which is secured by SHA256 hash. This hash is embedded in the signed kernel image (both are built in the same process). The kernel will then validate the core file system with this hash before accessing it, therefore maintaining the chain of trust.
Access to kernel memory (direct and indirect) is restricted to the microkernel only. All drivers run as user space processes, hence with zero access to kernel memory. Direct access to hardware resources other than memory (register space) is restricted to drivers loaded from the (verified) core file system.
The above mechanisms are always in effect, independent from whether SecureBoot is active or not.
When lockdown is in effect, a number of features are disabled or have their use restricted. This includes special device files and kernel services that allow direct access of the kernel image:
/dev/mem /dev/kmem /dev/kcore /dev/ioports BPF kprobesand the ability to directly configure and control devices, so as to prevent the use of a device to access or modify a kernel image:
Special device files or other interfaces to access kernel memory are not provided. IO port access is only granted for drivers from the core file system.
- The use of module parameters that directly specify hardware parameters to drivers through the kernel command line or when loading a module.
Directly specifying hardware parameters is not supported for any driver. Hardware drivers are configured through PCI or ACPI information or through fixed information stored in the core file system.
- The use of direct PCI BAR access.
Direct PCI BAR access is only allowed for hardware drivers in the core file system.
- The use of the ioperm and iopl instructions on x86.
ioperm and iopl functions are not available in Symobi.
- The use of the KD*IO console ioctls.
KD*IO console ioctls or similar functionality is not available in Symobi.
- The use of the TIOCSSERIAL serial ioctl.
Serial port configuration is not supported .
- The alteration of MSR registers on x86.
Access to MSRs is restricted to the kernel.
- The replacement of the PCMCIA CIS.
replacement of the PCMCIA CIS is not supported by Symobi.
- The overriding of ACPI tables.
overriding of ACPI tables is not supported by Symobi.
- The use of ACPI error injection.
ACPI error injection is not supported by Symobi.
- The specification of the ACPI RDSP address.
specification of the ACPI RDSP address is not supported in Symobi.
- The use of ACPI custom methods.
Custom ACPI methods are not supported by Symobi.
Certain facilities are restricted:
- Only validly signed modules may be loaded (waived if the module file being loaded is vouched for by IMA appraisal).
Kernel modules as in Linux are not supported in Symobi. Hardware access is only allowed for drivers in the core file system.
- Only validly signed binaries may be kexec'd (waived if the binary image file to be executed is vouched for by IMA appraisal).
Kexec (or similar functionality) is not supported by Symobi.
- Unencrypted hibernation/suspend to swap are disallowed as the kernel image is saved to a medium that can then be accessed.
Hibernation is not supported by Symobi.
- Use of debugfs is not permitted as this allows a whole range of actions including direct configuration of, access to and driving of hardware.
debugfs is not supported in Symobi. Some hardware drivers can output current configuration information, but configuration or custom commands are not supported.
- IMA requires the addition of the "secure_boot" rules to the policy, whether or not they are specified on the command line, for both the built-in and custom policies in secure boot lockdown mode.
We currently automatically inject a boot parameter through the MultiBoot or EFI chain loader command if SecureBoot is active and grub is locked down. This forces the use of an IOMMU and usage of NX. All other restrictions are always active, even if SecureBoot is not enabled.
Loaded code is validated through shim. Linux and Symobi are validated through upstream shim_lock. Other grub loader modules are blocked while SecureBoot is active.
No, we use SHIM only to load GRUB2 with shim_lock module and SecureBoot patches from rhboot. Linux kexec is disabled Symobi does not support loading other kernels
- Linux: Version 6.1.15 with additional lockdown patches from Debian.
- Automatic lockdown if booted in SecureBoot
- Linux option to start other kernels (kexec) is DISABLED
- Linux option CONFIG_KGDB is disabled
- Applied patches are
- features/all/lockdown/efi-add-an-efi_secure_boot-flag-to-indicate-secure-b.patch
- features/all/lockdown/efi-lock-down-the-kernel-if-booted-in-secure-boot-mo.patch
- features/all/lockdown/mtd-disable-slram-and-phram-when-locked-down.patch
- features/all/lockdown/arm64-add-kernel-config-option-to-lock-down-when.patch The patches are currently available through https://salsa.debian.org/kernel-team/linux/tree/master/ commit hash 20fd32da6e7e0ddc31f3af13de8d112d54e67d57