UEFI SECURE BOOT - WINDOWS 11 UND Monterey (DUALBOOT MIT OPENCORE) Teil 1

  • Danke a1k0n für den Hinweis bzgl der (UEFI) Secure Boot Thematik. Die Behebung hat mich dann doch sehr interessiert und es ist ein längerer Guide herausgekommen.

    Ich hab den Text offline geschrieben und paste den hier einfach mal rein. Screenshots habe ich griffbereit und die werde ich nach und nach einpflegen.

    Die Screenshots und die Anleitung fürs Bios basieren auf meinem Gigabyte Z390 Aorus Pro; BiosVer F12l.


    UEFI Secure Boot und Dual Boot OC-macOS/Windows 10/11


    Worum geht es _nicht_ in dem Guide:

    In diesem Guide geht es nicht um die wirksame Absicherung des Bootvorgangs mittels UEFI Secure Boot. Eine umfängliche Betrachtung sprengt den Rahmen dieses Guides.


    Worum geht es in dem Guide:

    In diesem Guide geht es darum, eine Mindestanforderungen “(UEFI) Secure Boot” für Windows 11 zu aktivieren und die dadurch entstehenden Auswirkungen, dass anschließend nicht-signierte EFIs nicht mehr gestartet werden können, zu beheben.



    Ich selbst habe noch kein Windows 11, sondern bin in der Vorbereitung in Bezug auf die aktuellen Win11 Mindestvoraussetzungen (TPM, Secure Boot).

    Es gibt unterschiedliche Meinungen dazu, ob für den Betrieb von Win11, Features wie TPM oder Secure Boot nur vorhanden oder auch (dauerhaft) aktiviert sein müssen.

    Ich stütze mich hier ausschließlich auf meine Beobachtungen auf meiner Plattform und die sind, dass Windows Update erst _nach_ der Aktivierung von TPM und Secure Boot meldet, dass meine Plattform die Mindestvoraussetzungen für Win11 erfüllt, während der Windows 11 Kompatibiltätschecker bereits ohne Aktivierung von Secure Boot die Readyness bestätigte.

    Meine Beobachtung ist auch, dass auf meiner Plattform ein im Bios aktiviertes (UEFI) Secure Boot dazu führt, dass unsignierte oder einer vom Bios nicht per Public Key überprüfbaren Signatur versehenen Bootloader mit folgender Meldung (erwartungsgemäß) blockiert werden:


    Um also Windows 11 via Windows Update bekommen zu können, fehlte mir zuletzt noch die Aktivierung von Secure Boot im Bios, jedoch mit dem Seiteneffekt dass dann reFind und OC und somit macOS nicht mehr startbar waren.



    Warum kann trotz aktivem Secure Boot Win10/11 starten und warum startet reFind bzw OC nicht?

    Weil Microsoft den Windows Bootloader digital signiert und mein Mainboardhersteller den passenden Public Key zur Validierung auf meinem Board im Bios hinterlegt hat.

    Mein reFind und OC Bootloader ist aktuell nicht digital signiert. Daher schlägt Secure Boot wegen fehlender digitaler Signatur fehl.


    Das Ziel des Lösungswegs ist somit klar: die unsignierten Bootloader benötigen eine digitale Signatur und diese digitale Signatur muss über die im Bios hinterlegten Public Keys validiert werden können.

    Ich möchte hier 2 Wege vorstellen:

    1. Enroll EFI Image
      Vorteil: Das geht ad-hoc aus dem Bios
      Nachteil: geänderte EFIs (OC-Update) müssen jedesmal neu Enrollt werden. Es sammeln sich ggfs alte Enrollments im Bios
    2. Signieren mit eigenem Zertifikat
      Vorteil: Man kann während des OC Updateprozesses die relevanten EFIs per sbsign signieren und muss das nicht im Bios nachpflegen.
      Nachteil: Man benötigt extra Tools wie sbsign und openssl. Man muss die Zertifikate erstellen und sicher verwahren.


    Beide Verfahren können auch kombiniert werden. Sollte man bei einem Update das signieren per sbsign vergessen haben, kann man über Enroll EFI Image das temporär nachholen und später wieder herauslöschen.


    Die zwei Verfahren habe ich selbst ausprobiert und unten dokumentiert.


    Variante1: Enroll EFI Image über das Gigabyte Bios


    Zuerst habe habe mich für den am einfachsten zu realisierenden Lösungsweg entschieden, in dem ich die im Gigabyte Bios eingebaute Funktion zur Validierung von EFIs nutze.


    Das Bios meines Gigabyte Z390 Aorus Pro Boards hat eine Funktion eingebaut, mit der man ad-hoc EFIs für Secure Boot validieren kann.

    Grob funktioniert das so, dass über das Bios in einem Dialog mountbare (FAT) Partitionen angezeigt werden. Durch diese kann man zur einer EFI navigieren und diese dann für die Validierung auswählen. Die für die Validierung nötigen Informationen werden dabei im Bios hinterlegt. Anschließend lässt sich ein so validiertes EFI auch mit Secure Boot starten.


    Da ich keine Veränderung an den validierten EFIs via shasum feststellen konnte, gehe ich davon aus, dass der Validierungsprozess einen digitalen Fingerabdruck des EFIs erstellt und diesen im Bios hinzufügt. Tatsächlich wird sha256 als Signaturtyp benutzt und im Gigabyte Bios unter Authorized Signatures eingetragen.


    Das Hinzufügen individueller digitaler Fingerabdrücke ins Bios führt mich direkt zur Frage, wie viele kann man da hinterlegen, kann man Alte löschen? Hierauf habe ich für mich noch keine konkrete Antwort, ausser dass das Gigabyte Bios eine Funktion bietet, den Validierungsstore zu resetten bzw einzelne oder alle Authorized Signatures zu löschen. Das habe ich aber noch nicht ausprobiert und kann noch keine Aussage zu den Auswirkungen treffen.


    Vorbereitung:

    Im Bios werden die Disks in einer Reihenfolge auflistet, die wahrscheinlich den SATA Ports entspricht.

    Um auf Nummer Sicher zu gehen, könnte man vorab die EFI-Partitionen mit einem Dummy-Ordner “SignME” kennzeichnen.


    WIchtig:

    Macht euch Screenshots vom Bios im Bereich Secure Boot. Im Gigabyte Bios kann man das mit F12 machen. Steckt dazu einen Fat-formatierten USB Stick ein drückt F12. Der Screenshot landet auf dem USB Stick.

    Macht euch Screenshots von den Inhalten der einzelnen Secure Boot Variablen Platform Key(PK), Key Exchange Keys und Authorized Signatures - jeweils reingehen und auf Details klicken und dann Screenshot, damit ihr Anhaltspunkte habt das vorher drin war und was ihr hinzugefügt habt.


    Schritt 1:

    Ins Bios gehen und Secure Boot aktivieren und Bios Änderungen Speichern. Achtet darauf dass "Secure Boot Mode" auf Custom steht, damit KeyManagement zugänglich ist.


    Optional: das Bios an dieser Stelle nach dem Speichern verlassen und ersten Test durchführen: Windows sollte weiterhin booten können. OC-macOS jedoch nicht.





    Schritt 2: OC Validieren

    Damit OC Secure Boot klappt müsst ihr mind diese .efi validieren:

    BOOT/Bootx64.efi

    OC/OpenCore.efi

    OC/Drivers/OpenRuntime.efi

    (Die anderen EFIs in Drives habe ich nicht validiert. Falls ich diese punktuell brauche , werde ich temporär Secure Boot ausschalten.)


    -> Im Bios zu Key Management gehen und dort Enroll EFI Image auswählen


    -> In der Liste der Filesystems eure Disk und Partition mit OC auswählen und nacheinander die Dateien

    BOOT/Bootx64.efi

    OC/OpenCore.efi

    OC/Drivers/OpenRuntime.efi

    validieren




    (Hier steht normalerweise "! Success". Bei mir steht "Already started", weil ich den Loader erneut Enrollt hab und bereits ein Eintrag in der DB ist)


    Schritt 3: Bios Änderungen Speichern, verlassen und neu starten


    Jetzt solltet ihr Windows on OC-macOS booten können.


    Optionale Schritte: Löschen von alten Signaturen

    In Authorized Signatures kann man über "Delete -> No" einzelne Signaturen wieder löschen.

    Achtet bei Delete und andern Aktivitäten immer genau auf den Text im Yes - No Dialog.



    Troubleshooting:



    Solltet ihr o.g. Meldung erhalten, solltet ihr prüfen, ob ihr das korrekte EFI Enrollt habt.

    Bei OC müsst ihr daran denken, dass da mehrere EFIs enrollt werden müssen.

    Alternativ könnt ihr UEFI Secure Boot im Bios erst mal wieder deaktivieren.





    Teil 2 folgt hier SECURE BOOT - WINDOWS 11 UND MONTEREY (DUALBOOT MIT OPENCORE) TEIL 2

    Edited 6 times, last by talkinghead: Formulierung auf "UEFI Secure Boot" geändert ().

  • Coole Anleitung,


    allerdings muss ich sagen das ich Secureboot und TPM 2.0 anhabe , keine EFI signiert habe und trotzdem sauber booten kann inkl Windows 11 (von dem ich grade schreibe) also irgendwas ist hier dann doch faul oder ?


    selbst whynotwin11 sagt das alles aktiv ist O.o



    KEIN SUPPORT PER PN!

    julian2_pic.png

  • Bestätige dass ich auf meinem Z590 Vision G mit Bios F5 ohne gewurschtel, auch SecureBootMode enabled und TPM 2.0 aktive auf WIN11, macOS 11/12 ohne Probleme switchen kann!


    Benutze OpenCore 0.7.5 nightly.


    Versuchsweise auch Linux, klappt alles super

    Bootloader: Open Core

    MoBo: Gigabyte Z590 Vision G

    WiFi : intel AX3000 WiFi 6 / BCM4360

    CPU : Intel Core i9 10850K 10x 3.60GHz
    GPU : Radeon RX 5700 8GB
    Mem : 32 GB DDR4 3600 4x 8GB
    SSD M2: OSX 11 / OSX 12
    SSD M2: WIN11 / Linux
    Case: Corsair Carbide Series 275R

  • Beim 2. Lösungsweg würde ich noch anmerken das OpenCore.efi und Bootx64.efi erst signiert werden müssen mit den eignen Zertifikaten bevor man sie nochmal signiert mit sig.command im Falle man nutzt zusätzlich Apple Secure Boot mit Vault -> Secure in der config.plist. Ansonsten lässt es sich nicht booten weil OpenCore Fehler ausspuckt. Ansonsten super Anleitung 👍

    • Gigabyte z390 Gaming M
    • i7-9700k
    • MQUPIN Gigabit-Netzwerkkarte, BCM94360CS2 (nativ)
    • Sapphire RX 580 Nitro+
    • OpenCore 0.6.3
    • 11.0.1 (20B28

  • Vielleicht reden wir von 2 verschiedenen "Secure Boot":

    Es gibt "UEFI Secure Boot" und es gibt "Apple Secure Boot".

    Ich beziehe mich auf UEFI Secure Boot.

    Meinen Beobachtungen nach, verhält sich UEFI Secure Boot bei mir genau so wie ich es erwarte:

    Ist UEFI Secure Boot im Bios aktiviert, kann ich nur diejenigen Bootloader starten die signiert oder Enrollt sind.

    Mein OC und reFind sind jetzt mit einem eigenen Zertifikat signiert.

    Wenn UEFI Secure Boot an ist und ich den öffentlichen Schlüssel meines Zertifikat aus dem DB-Store im Bios entferne, erscheint eine BIOS-Meldung "Invalid signature detected. Check Secure Boot Policy in Setup". Das ist genau das was ich auch erwarte, dass UEFI Secure Boot -wenn an- unerlaubte EFIs blockiert.




    Wenn ich dann _meinen_ Public Key wieder in den Bios DB Store einfüge, kann ich die vorher blockierten EFIs starten. Genau so wie es zu erwarten ist.

    Wie schon erwähnt: das hat nichts mit Apple Secure Boot und OC/config.plist zu tun. Das ist _vor_ dem Laden von OC.

  • talkinghead

    Changed the title of the thread from “SECURE BOOT - WINDOWS 11 UND Monterey (DUALBOOT MIT OPENCORE) Teil 1” to “UEFI SECURE BOOT - WINDOWS 11 UND Monterey (DUALBOOT MIT OPENCORE) Teil 1”.
  • Ich rede auch von UEFI Secure Boot.

    sonst würde das W11 tool auch nicht grün ausschlagen das secureboot aktiv wäre


    KEIN SUPPORT PER PN!

    julian2_pic.png

  • whynotwin11 sagt bei dir nicht, dass secure boot aktiviert ist. Es wird nur geprüft, ob die Hardware secure boot unterstützt. Ich hab mein System auch ohne aktiviertes secure boot von 10 auf 11 upgraden können und bei dem Check wurde mir das auch grün angezeigt. Habe das gerade testweise auch noch mal bei whynotwin11 gemacht (mit deaktiviertem secure boot) und da ist auch alles grün bei mir :D Ich denke deswegen kam die Frage auf, ob wirklich secure boot aktiv ist, weil das das Tool eben nicht anzeigt. :)

    ASrock Fatal1ty Z370 Professional Gaming i7
    Intel i7-8086k
    Asus Radeon RX 580
    32GB Ballistix Sport LT DDR4-2666

  • xrabit


    komisch bei mir zeigt whynotw11 rot an wenn secureboot aus ist.

    und auf nem technik DC wo ich aktiv bin haben wir viele fälle wo secureboot aus ist und das toll auch rot wirft.


    KEIN SUPPORT PER PN!

    julian2_pic.png

  • Okay dann ist das echt seltsam, so sieht das bei mir nämlich mit deaktiviertem Secure Boot aus :D


    ASrock Fatal1ty Z370 Professional Gaming i7
    Intel i7-8086k
    Asus Radeon RX 580
    32GB Ballistix Sport LT DDR4-2666

  • Ich bin grade maximal verwirrt ... ich bin 100% sicher das SB eingeschaltet war !

    grade extra ins bios geschaut und es war wieder aus ... eingeschaltet und bekomme das signatur problem


    KEIN SUPPORT PER PN!

    julian2_pic.png

  • julian91 : Wenn UEFI Secure Boot bei dir an ist und dennoch unlinierte Bootloader durchlässt, dann hast du glücklicherweise keinen Handlungsbedarf. Passt ja. Es muss ja UEFI Secure Boot nicht auf jedem Board richtig funktionieren und unsignierte Loader blocken. Hauptsache die Betriebssysteme starten.

  • Auf meinem B460M DS3H auch von Gigabyte verhält es sich wie bei talkinghead wenn ich Secure Boot und TPM aktiviere.


    Aktiviere ich es nicht zeigt mir der Win11 Update Checker an das ich TPM nicht aktiviert habe und nicht updaten kann, aktiviere ich es ist der Win11 Update Checker grün aber ich komm nicht mehr in den OC Bootmanager.


    Am besten klingt es aktuell das im Bios zu "enrollen". Da ich mich mit dem Thema Sec Boot/TPM/Signieren noch nicht intensiv beschäftigt habe noch ein paar Fragen:

    - Wenn ich OC im Bios "enrolle" sagtest du ich muss die irgendwie auswählen. Das bedeutet ich muss meinen Rettungsstick auch da reinbekommen?

    - Was ist das Kriterium das ich einen neuen Enroll brauche? Eine geänderte bootx64.efi oder schon die änderung der confif.plist oder eine kextupdate?


    Gruss,

    Joerg

  • talkinghead

    xrabit


    So , nachdem ich SB eingeschaltet hatte war sense ...


    allerdings bietet auch ASRock im Bios die Möglichkeit zu signieren ...

    allerdings musste ich hier ALLE .efi files signieren damit er sauber OC Bootet , war in meinem Fall die Boot64 , opencore.efi , hfsplus.efi und openruntime.efi...


    aber jetzt ist secureboot an und ich kann per OC booten, nice :)

    Die Anleitung hat mir jedenfalls den weg in die richtige richtung in meinem bios gegeben


    KEIN SUPPORT PER PN!

    julian2_pic.png

  • MPC561 :

    Bzgl. Rettungsstick: Theoretisch müsste es so klappen, dass Du die *.efis auf der Bootpartition enrollst und dann genau diese *.efis auf den Rettungsstick kopierst, weil dann diese *.efis die identische Hash (sha256) haben, wie die auf der Platte. Das müsste gehen. Vielleicht kannst du das ausprobieren und hier posten.


    Neu enrollen musst du nur dann, wenn einer der entrollten Binaries sich ändert. Config etc zählt nicht mit.


  • und hier auch der "beweiß" das es aktiv ist :) :D


    KEIN SUPPORT PER PN!

    julian2_pic.png

  • Hauptsache es funktioniert :D werde das morgen auch mal nach der Anleitung hier machen. Da ich auch ein ASRock Board wie julian91 habe, sollte ich die Option mit dem Enroll ja hoffentlich auch haben :D

    ASrock Fatal1ty Z370 Professional Gaming i7
    Intel i7-8086k
    Asus Radeon RX 580
    32GB Ballistix Sport LT DDR4-2666

  • Ein Freund von mir, daniel14513 hier im Board , dem ich heute Nachmittag per WhatsApp Video geholfen habe das UEFI SecureBoot einzurichten, hat auch ein Z370er MB von ASUS. Diese haben wohl diesen Menüpunkt 'Enroll EFI' im Bios, was das ganze sehr vereinfacht. Mein MB, bzw. das Bios, hat diese Auswahl leider nicht. Daher bleibt denen die es nicht im Bios haben nur der Weg, die *.efi Boot Dateien per sbsign unter Linux zu signieren. ALLE Startdateien, die in der config.plist unter UEFI->Drivers eingetragen sind (und dito die BOOTx64.efi in /EFI/BOOT und die OpenCore.efi in /EFI/OC), müssen signiert werden, sonst stockt OC beim starten. Das hatten wir heute, weil wir vergaßen die HfsPlus.efi zu signieren. Erst danach startete OC durch.

    Gruß, karacho


    Bitte keine Supportanfragen via PN. Eure fragen gehören ins Forum!

    Ich hab noch drei Patronen, eine für dich und zwei für mich...

  • Wer Enroll EFI im Bios hat brauch natürlich nichts signieren und kann sich glücklich schätzen. Auf dem Laptop würde da zusätzlich ein Biospasswort sinn machen. (zwecks verloren gehen)

    • Gigabyte z390 Gaming M
    • i7-9700k
    • MQUPIN Gigabit-Netzwerkkarte, BCM94360CS2 (nativ)
    • Sapphire RX 580 Nitro+
    • OpenCore 0.6.3
    • 11.0.1 (20B28