shim-review

Dieses Repo dient der Überprüfung von Anfragen zur Signierung von Shim. Um eine Überprüfungsanfrage zu erstellen:

• dieses Repo klonen (vorzugsweise forken)
• die Vorlage unten bearbeiten
• die zu signierende shim.efi hinzufügen
• Build-Protokolle hinzufügen
• alle zusätzlichen Binärdateien/Zertifikate/SHA256-Hashes hinzufügen, die benötigt werden könnten
• alles committen
• mit einem Tag der Form "myorg-shim-arch-YYYYMMDD" taggen
• nach GitHub pushen
• ein Issue unter https://github.com/rhboot/shim-review/issues mit einem Link zu Ihrem Tag erstellen
• die Freigabe ist bereit, wenn das Label "accepted" zu Ihrem Issue hinzugefügt wurde

Beachten Sie, dass wir wirklich nur Erfahrung mit der Verwendung von GRUB2 oder systemd-boot unter Linux haben. Wenn Sie uns bitten, etwas anderes zur Signierung zu unterstützen, müssen Sie uns davon überzeugen.

Ab dem 20. Oktober 2025 werden an Microsoft gesendete Shims mit den Schlüsseln von 2011 und 2023 signiert. Für jeden von Ihnen eingereichten Shim erhalten Sie zwei Kopien zurück, die jeweils mit einem anderen Schlüssel signiert sind. Hier die neuesten Informationen von Microsoft: https://techcommunity.microsoft.com/blog/hardware-dev-center/signing-with-the-new-2023-microsoft-uefi-certificates-what-submitters-need-to-kn/4455787

Es sind auch neue Signieranforderungen in Kraft getreten, die hier verfügbar sind: https://techcommunity.microsoft.com/blog/hardware-dev-center/updated-microsoft-uefi-signing-requirements/1062916 Bitte beachten Sie, dass diese Shim-Überprüfung Sie von jährlichen Sicherheitsaudits befreit, solange Ihr Shim nur an Open-Source-Bootloader übergibt.

Hinweis: Schauen Sie sich das docs-Verzeichnis in diesem Repo an, um Anleitungen zur Einreichung und zur Signierung Ihres Shims zu erhalten.

Hier ist die Vorlage:

Welche Organisation oder welche Personen bitten um die Signierung?

Organisationsname und Website:
[Ihr Text hier]

Welche rechtlichen Daten belegen die Echtheit der Organisation?

Die Prüfer sollten leicht überprüfen können, dass Ihre Organisation eine juristische Person ist, um Missbrauch zu verhindern. Geben Sie die Informationen an, die die Echtheit zweifelsfrei belegen können.

Einträge im Handels-/Steuerregister oder gleichwertiges:
(ein Link zum Organisationseintrag im Register Ihrer Gerichtsbarkeit genügt)

[Ihr Text hier]

Die öffentlichen Details sowohl Ihrer Organisation als auch des Ausstellers im EV-Zertifikat, das zum Signieren von .cab-Dateien bei den Microsoft Hardware Dev Center File Signing Services verwendet wird.
(nicht das in Ihrem Shim-Binär eingebettete CA-Zertifikat)

Beispiel:``` Issuer: O=MyIssuer, Ltd., CN=MyIssuer EV Code Signing CA Subject: C=XX, O=MyCompany, Inc., CN=MyCompany, Inc.

[Ihr Text hier]
*******************************************************************************
### Für welches Produkt oder welchen Dienst ist dies gedacht?
*******************************************************************************
[Ihr Text hier]

*******************************************************************************
### Was ist die Begründung, dass dies wirklich signiert werden muss, damit die ganze Welt es booten kann?
*******************************************************************************
[Ihr Text hier]

*******************************************************************************
### Warum können Sie keinen Shim von einer anderen Distribution verwenden, der bereits signiert ist?
*******************************************************************************
[Ihr Text hier]

*******************************************************************************
### Wer ist der primäre Kontakt für Sicherheitsupdates usw.?
Die Sicherheitskontakte müssen überprüft werden, bevor der Shim akzeptiert werden kann. Bei späteren Anfragen ist eine Kontaktüberprüfung nur erforderlich, wenn sich die Sicherheitskontakte oder ihre PGP-Schlüssel seit der letzten erfolgreichen Überprüfung geändert haben.

Ein autorisierter Prüfer wird die Kontaktüberprüfung einleiten, indem er jedem Sicherheitskontakt eine PGP-verschlüsselte E-Mail mit zufälligen Wörtern sendet.
Sie werden gebeten, den Inhalt dieser E-Mails in Ihrem `shim-review`-Issue zu veröffentlichen, um die Inhaberschaft der E-Mail-Adressen und PGP-Schlüssel nachzuweisen.
Bitte laden Sie die PGP-Schlüssel auf einen bekannten Keyserver wie keyserver.ubuntu.com hoch und/oder fügen Sie sie als .asc-Datei in die Überprüfung ein und verweisen Sie hier darauf.

*******************************************************************************
- Name:
- Position:
- E-Mail-Adresse:
- PGP-Schlüssel-Fingerabdruck:
- Datei-/Keyserver-Speicherort:

*******************************************************************************
### Wer ist der sekundäre Kontakt für Sicherheitsupdates usw.?
*******************************************************************************
- Name:
- Position:
- E-Mail-Adresse:
- PGP-Schlüssel-Fingerabdruck:
- Datei-/Keyserver-Speicherort:

*******************************************************************************
### Wurden diese Binärdateien aus dem 16.1-Shim-Release-Tar erstellt?
Bitte erstellen Sie Ihre Shim-Binärdateien ausgehend von der 16.1-Shim-Release-Tar-Datei: https://github.com/rhboot/shim/releases/download/16.1/shim-16.1.tar.bz2

Dies entspricht https://github.com/rhboot/shim/releases/tag/16.1 und enthält den entsprechenden gnu-efi-Quellcode.

Stellen Sie sicher, dass das Tarball korrekt ist, indem Sie die Prüfsumme Ihres Downloads überprüfen
(SHA256, SHA512) mit den folgenden:```
46319cd228d8f2c06c744241c0f342412329a7c630436fce7f82cf6936b1d603  shim-16.1.tar.bz2
ca5f80e82f3b80b622028f03ef23105c98ee1b6a25f52a59c823080a3202dd4b9962266489296e99f955eb92e36ce13e0b1d57f688350006bba45f2718f159fb  shim-16.1.tar.bz2

Stellen Sie sicher, dass Sie überprüft haben, dass Ihr Build-Prozess diese Datei als Quelle der Wahrheit verwendet (exklusive externer Patches) und ihre Prüfsumme übereinstimmt. Sie können die Veröffentlichung auch weiter validieren, indem Sie die PGP-Signatur überprüfen: Es gibt eine abgetrennte Signatur

Die Veröffentlichung ist vom Maintainer Peter Jones signiert – sein Hauptschlüssel hat den Fingerabdruck B00B48BC731AA8840FED9FB0EED266B70F4FEF10 und der Unterzeichnungsschlüssel in der Signatur hier hat den Fingerabdruck 02093E0D19DDE0F7DFFBB53C1FD3F540256A1372. Eine Kopie seines öffentlichen Schlüssels finden Sie hier als Referenz: pjones.asc

Wenn Sie sicher sind, dass das von Ihnen verwendete Tarball korrekt und authentisch ist, bestätigen Sie dies bitte hier mit einem einfachen yes.

Eine kurze Anleitung zur Überprüfung von öffentlichen Schlüsseln und Signaturen finden Sie im docs-Verzeichnis.

[Ihr Text hier]

URL zu einem Repository, das den genauen Code enthält, der erstellt wurde, um Ihre Binärdatei zu erhalten:

Hinweis: Wenn Sie alle Patches und Modifikationen, die in Ihrer Anwendung verwendet werden, anhängen, können Sie hier auf die URL Ihrer Anwendung verweisen (https://github.com/YOUR_ORGANIZATION/shim-review).

Sie können auch auf Ihre benutzerdefinierten Git-Server verweisen, auf denen der Code gehostet wird.

[Ihre URL hier]

Welche Patches werden angewendet und warum:

Erwähnen Sie alle externen Patches und Build-Prozess-Modifikationen, die während Ihres Build-Prozesses verwendet werden und dafür sorgen, dass Ihre Shim-Binärdatei genau die ist, die Sie als Teil dieser Bewerbung eingereicht haben.

[Ihr Text hier]

Haben Sie das NX-Bit in Ihrer Shim gesetzt? Falls ja, ist Ihr gesamter Boot-Stack NX-kompatibel und welche Tests haben Sie durchgeführt, um diese Kompatibilität sicherzustellen?

Siehe https://techcommunity.microsoft.com/t5/hardware-dev-center/nx-exception-for-shim-community/ba-p/3976522 für weitere Details zur Signierung von Shim ohne NX-Bit.

[Ihr Text hier]

Welche genaue Implementierung von Secure Boot in GRUB2 haben Sie? (Entweder Upstream-GRUB2-shim_lock-Verifier oder Downstream-RHEL/Fedora/Debian/Canonical-ähnliche Implementierung)

Überspringen Sie dies, wenn Sie GRUB2 nicht verwenden.

[Ihr Text hier]

Haben Sie Korrekturen für alle folgenden GRUB2-CVEs angewendet?

Überspringen Sie dies, wenn Sie GRUB2 nicht verwenden, andernfalls stellen Sie sicher, dass diese vorhanden sind, und bestätigen Sie mit yes.

• Juli 2020 - 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
• März 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 (wenn Sie das shim_lock-Modul ausliefern)
  • CVE-2021-20225
  • CVE-2021-20233
• Juni 2022
  • Details: https://lists.gnu.org/archive/html/grub-devel/2022-06/msg00035.html, SBAT-Erhöhung auf 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-Erhöhung auf 3
  • CVE-2022-2601
  • CVE-2022-3775
• Oktober 2023 - NTFS-Sicherheitslücken
  • Details: https://lists.gnu.org/archive/html/grub-devel/2023-10/msg00028.html, SBAT-Erhöhung auf 4
  • CVE-2023-4693
  • CVE-2023-4692
• Februar 2025
  • Details: https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00024.html, SBAT-Erhöhung auf 5
  • CVE-2024-45774
  • CVE-2024-45775
  • CVE-2024-45776
  • CVE-2024-45777
  • CVE-2024-45778
  • CVE-2024-45779
  • CVE-2024-45780
  • CVE-2024-45781
  • CVE-2024-45782
  • CVE-2024-45783

[Ihr Text hier]

Wenn Shim den GRUB2-Bootloader lädt und diese Korrekturen angewendet wurden, ist die globale Upstream-SBAT-Generation in Ihrer GRUB2-Binärdatei auf 5 gesetzt?

Überspringen Sie dies, wenn Sie GRUB2 nicht verwenden, andernfalls: Haben Sie einen Eintrag in Ihrer GRUB2-Binärdatei ähnlich wie:
grub,5,Free Software Foundation,grub,GRUB_UPSTREAM_VERSION,https://www.gnu.org/software/grub/?

[Ihr Text hier]

Wurden alten Shim-Hashes Microsoft zur Überprüfung und zur Aufnahme in zukünftige DBX-Updates zur Verfügung gestellt?

Erlaubt Ihre neue Vertrauenskette das Booten alter, von den CVEs betroffener GRUB2-Builds nicht?

Wenn Sie noch nie einen signierten Shim hatten, sagen Sie dies hier. Andernfalls reicht ein einfaches yes.

[Ihr Text hier]

Wenn Ihre Boot-Vertrauenskette einen Linux-Kernel enthält:

Ist der Upstream-Commit 1957a85b0032a81e6482ca4aab883643b8dae06e "efi: Restrict efivar_ssdt_load when the kernel is locked down" angewendet?

Ist der Upstream-Commit 75b0cea7bf307f362057cc778efe89af4c615354 "ACPI: configfs: Disallow loading ACPI tables when locked down" angewendet?

Ist der Upstream-Commit eadb2f47a3ced5c64b23b90fd2a3463f63726066 "lockdown: also lock down previous kgdb use" angewendet?

Hinweis: Upstream-Kernel sollten alle diese angewendet haben, aber wenn Sie Ihren eigenen stark modifizierten älteren Kernel ausliefern, der getrennt vom Upstream gewartet wird, könnte dies nicht der Fall sein.
Wenn Sie einen älteren Kernel ausliefern, überprüfen Sie Ihre Quellen doppelt; vielleicht haben Sie nicht alle Patches, sondern liefern eine Konfiguration aus, die die Probleme nicht exponiert.

[Ihr Text hier]

Wie erzwingt Ihr signierter Kernel den Lockdown, wenn Ihr System mit aktiviertem Secure Boot läuft?

Hinweis: Wenn nicht, werden wir Ihren Shim wahrscheinlich nicht signieren.

[Ihr Text hier]

Bauen Sie Ihren signierten Kernel mit zusätzlichen lokalen Patches? Was bewirken diese?

[Ihr Text hier]

Verwenden Sie einen flüchtigen Schlüssel zum Signieren von Kernelmodulen?

Wenn nicht, beschreiben Sie bitte, wie Sie sicherstellen, dass ein Kernel-Build keine Module lädt, die für einen anderen Kernel gebaut wurden.

[Ihr Text hier]

Wenn Sie die vendor_db-Funktionalität zur Bereitstellung mehrerer Zertifikate und/oder Hashes verwenden, beschreiben Sie bitte kurz Ihre Zertifikatseinrichtung.

Wenn es auf einer Whitelist stehende Hashes gibt, geben Sie bitte genaue Binärdateien an, für die Hashes über einen Dateifreigabedienst erstellt werden, der öffentlich mit anonymem Zugriff zur Überprüfung verfügbar ist.

[Ihr Text hier]

Wenn Sie das CA-Zertifikat Ihres letzten Shim-Binärs wiederverwenden, müssen Sie die Hashes der früheren, den oben genannten CVEs ausgesetzten GRUB2-Binärdateien zu vendor_dbx in shim hinzufügen. Bitte beschreiben Sie Ihre Strategie.

Dadurch wird sichergestellt, dass Ihr neuer Shim+GRUB2 diese älteren GRUB2-Binärdateien mit Problemen nicht mehr chainloaden kann.

Wenn dies Ihre erste Bewerbung ist oder Sie ein neues CA-Zertifikat verwenden, sagen Sie dies bitte hier.

[Ihr Text hier]

Ist das Dockerfile in Ihrem Repository das Rezept zur Reproduktion des Builds Ihres Shim-Binärs?

Ein Reviewer sollte immer in der Lage sein, docker build . auszuführen, um das genaue Binär zu erhalten, das Sie Ihrer Bewerbung beigefügt haben.

Hinweis: Verwenden Sie bevorzugt eingefrorene Pakete für Ihre Toolchain, da ein Update von GCC, binutils, gnu-efi dazu führen kann, dass ein Shim-Binär mit einer anderen Prüfsumme gebaut wird.

Wenn Ihre Shim-Binärdateien nicht mit dem bereitgestellten Dockerfile reproduziert werden können, erklären Sie bitte, warum das der Fall ist, was die Unterschiede wären und welche Build-Umgebung (Betriebssystem und Toolchain) verwendet wird, um diesen Build zu reproduzieren? In diesem Fall schreiben Sie bitte eine detaillierte Anleitung, wie diese Build-Umgebung von Grund auf eingerichtet wird.

[Ihr Text hier]

Welche Dateien in diesem Repository sind die Logs für Ihren Build?

Dies sollte Logs für das Erstellen der Buildroots, das Anwenden von Patches, das Ausführen des Builds, das Erstellen der Archive usw. enthalten.

[Ihr Text hier]

Welche Änderungen wurden in der Secure-Boot-Kette der Distribution seit der letzten Signierung Ihres SHIM vorgenommen?

Zum Beispiel Signierung neuer Kernel-Varianten, UKI, systemd-boot, neue Zertifikate, neue CA usw.

Überspringen Sie dies, wenn dies Ihre erste Bewerbung zur Signierung von Shim ist.

[Ihr Text hier]

Was ist der SHA256-Hash Ihres endgültigen Shim-Binärs?

[Ihr Text hier]

Wie verwalten und schützen Sie die in Ihrem Shim verwendeten Schlüssel?

Beschreiben Sie die Sicherheitsstrategie, die für den Schlüsselschutz verwendet wird. Dies kann von der Verwendung von Hardware-Token wie HSMs oder Smartcards über luftdichte Tresore, physische Safe bis hin zu anderen bewährten Methoden reichen.

[Ihr Text hier]

Verwenden Sie EV-Zertifikate als eingebettete Zertifikate im Shim?

Ein yes oder no genügt. Es gibt keine Strafe für Letzteres.

[Ihr Text hier]

Betten Sie ein CA-Zertifikat in Ihren Shim ein?

Ein yes oder no genügt. Es gibt keine Strafe für Letzteres. Wenn jedoch yes: Enthält dieses Zertifikat die X509v3 Basic Constraints, die besagen, dass es sich um eine CA handelt? Siehe docs für weitere Hinweise dazu.

[Ihr Text hier]

Fügen Sie einen herstellerspezifischen SBAT-Eintrag im SBAT-Abschnitt jeder Binärdatei hinzu, die SBAT-Metadaten unterstützt (GRUB2, fwupd, fwupdate, systemd-boot, systemd-stub, shim + alle untergeordneten Shim-Binärdateien)?

Bitte geben Sie die genauen SBAT-Einträge für alle Binärdateien an, die Sie direkt über shim booten.

Hinweis: Die Geschichte von SBAT und weitere Informationen zur Funktionsweise finden Sie hier. Dieses Dokument ist umfangreich. Für einige Beispiele schauen Sie sich SBAT.example.md an.

Wenn Sie eine Downstream-Implementierung von GRUB2 (z. B. von Fedora oder Debian) verwenden, stellen Sie sicher, dass deren SBAT-Einträge erhalten bleiben und dass Sie Ihre eigenen anhängen (nicht ersetzen), um den Widerruf zu vereinfachen.

Denken Sie daran, die Einträge aller Binärdateien zu posten. Neben Ihrem Bootloader liefern Sie möglicherweise auch z. B. einen Firmware-Updater aus, der ebenfalls diese Einträge enthalten wird.

Hinweis: Führen Sie objcopy --dump-section .sbat=/dev/stdout IHR_EFI_BINARY aus, um diese Einträge zu erhalten. Fügen Sie sie hier ein. Umgeben Sie jede Auflistung vorzugsweise mit drei Backticks (```), damit sie gut dargestellt werden.

[Ihr Text hier]

Wenn Shim den GRUB2-Bootloader lädt, welche Module sind in Ihr signiertes GRUB2-Image integriert?

Überspringen Sie dies, wenn Sie GRUB2 nicht verwenden.

Hinweis: Es geht um die Module, die sich in der Binärdatei selbst befinden, nicht um die .mod-Dateien in Ihrem Dateisystem.

[Ihr Text hier]

Wenn Sie systemd-boot auf arm64 oder riscv verwenden, ist der Fix für unverifiziertes Devicetree-Blob-Laden enthalten?

[Ihr Text hier]

Was ist der Ursprung und die vollständige Versionsnummer Ihres Bootloaders (GRUB2 oder systemd-boot oder anderer)?

[Ihr Text hier]

Wenn Ihr Shim andere Komponenten außer Ihrem Bootloader startet, geben Sie bitte weitere Details dazu an, was gestartet wird.

Hinweis: Der häufigste Fall hier ist ein Firmware-Updater wie fwupd.

[Ihr Text hier]

Wenn Ihr GRUB2 oder systemd-boot andere Binärdateien als den Linux-Kernel im SecureBoot-Modus startet, geben Sie bitte weitere Details dazu an, was gestartet wird und wie es den Secureboot-Lockdown erzwingt.

Überspringen Sie dies, wenn Sie GRUB2 oder systemd-boot nicht verwenden.

[Ihr Text hier]

Wie verhindern die gestarteten Komponenten die Ausführung von nicht authentifiziertem Code?

Fassen Sie in ein oder zwei Sätzen zusammen, wie Ihre sichere Bootchain auf höherer Ebene funktioniert.

[Ihr Text hier]

Lädt Ihr Shim irgendwelche Loader, die das Laden von unsignierten Kerneln unterstützen (z. B. bestimmte GRUB2-Konfigurationen)?

[Ihr Text hier]

Welchen Kernel verwenden Sie? Welche Patches und Konfiguration enthält er, um Secure Boot zu erzwingen?

[Ihr Text hier]

Welche Beiträge haben Sie geleistet, um uns bei der Überprüfung der Bewerbungen anderer Antragsteller zu helfen?

Der Überprüfungsprozess ist als Peer-Review-Aufwand gedacht, und der beste Weg, Ihre Bewerbung schneller überprüft zu bekommen, ist, anderen bei der Überprüfung zu helfen. Wir sind in den meisten Fällen Freiwillige, die in unserer Freizeit an dieser Plattform arbeiten, und nicht Angestellte, die dafür bezahlt werden, Bewerbungen während unserer Geschäftszeiten zu überprüfen.

Eine angemessene Wartezeit für eine Überprüfung kann 2–3 Monate betragen. Uns zu helfen, ist der beste Weg, diesen Zeitraum zu verkürzen. Je mehr Hilfe wir bekommen, desto schneller und reibungsloser wird es laufen.

Für Neueinsteiger werden die als easy to review gekennzeichneten Bewerbungen empfohlen, um mit dem Beitragsprozess zu beginnen.

[Ihr Text hier]

Fügen Sie alle zusätzlichen Informationen hinzu, die wir Ihrer Meinung nach benötigen, um diese Shim-Signierungsbewerbung zu validieren.

[Ihr Text hier]