Secure Boot für Windows in OpenCore unmöglich auf Gigabyte Board??

  • Abend!


    Hab Gigabyte B760 Gaming X DDR4 mit dem neuesten BIOS. Intel CPU, AMD Grafikkarte. OpenCore läuft ohne Secure Boot tip top. Ich brauche kein Apple Secure Boot, ich brauche nur, dass Windows Secure Boot und TPM aktiviert haben kann - damit ich Battlefield 6 spielen kann :-D


    Ich habe versucht, die OpenCore EFI-Binärdateien und Treiber mit dieser Anleitung zu signieren: https://github.com/profzei/Mat…Secure-Boot-with-OpenCore.


    - In meine Ubuntu Partition gebootet, Schlüssel nach dem Guide generiert und meine OpenCore EFI-Partition gemountet.

    - Alle .efi Dateien, aus dem EFI mit den extrahierten privaten und öffentlichen Schlüsseln mit openssl signiert

    - Die signierten efi files zurück in den EFI-Bootloader gelegt und die privaten und öffentlichen Schlüssel in einen seperaten Ordner auf dem EFI kopiert, damit ich aus dem BIOS darauf zugreifen kann.


    Ich bin in mein BIOS gegangen und habe mehrere Ansätze versucht, aber es scheint unmöglich, Secure Boot mit OpenCore auf diesem Gigabyte-Mainboard zum Laufen zu bringen. Das ganze resultiert darin, dass ich meist einen schwarzen Screen hab und irgedwann auch der CPU Lüfter auffhört, also irgendein toter C-State erreicht wird.

    Zur Wiederherstellung muss ich das BIOS mit Q-Flash auf einem USB-Stick neu flashen (was meine generierten PK/KEK/db-Schlüssel denke ich mal vollständig obsolet macht (Oder bleiben die bestehen??).

    Es gibt jedoch EINE Methode, die Secure Boot zum Funktionieren bringt, aber mit einem großen Nachteil: Ich kann nicht auf das BIOS zugreifen und ich kann auch nicht in OpenCore booten. Es bootet einfach nach einem schwarzen Bildschirm und 2 Minuten Wartezeit direkt in Windows - ohne Auswahlmöglichkeiten. Um das wieder zurückzusetzen muss ich wieder Q-Flashen.


    Es ist absolut seltsam und der ganze Prozess dauert EWIG (seit gestern Mitternacht sitz ich hier dran.)


    ---


    Hier ist genau, was ich nach einem kompletten BIOS-Reset (Werkeinstellungen) gemacht habe, um wenigstens in den Windows-Secure-Boot-Modus zu gelangen:


    - XMP Profil 1 aktiviert

    - Re-Size BAR aktiviert

    - Bestätigt, dass CSM deaktiviert ist

    - Bestätigt, dass TPM aktiviert ist


    Erster Boot:


    1. Secure Boot auf Deaktiviert gesetzt

    2. Secure Boot von Standard auf Custom geändert

    3. Restore Vendor Keys - wenn aufgefordert 'Save Without Quit' gecanceled. (BIOS schaltet dann von Setup auf User Mode um)

    4. BIOS Einstellungen speichern und neu starten


    Zweiter Boot:


    1. Secure Boot von Custom zurück auf Standard geändert.

    2. Als aufgefordert, ohne Speichern neu zu starten → Abgebrochen

    3. Secure Boot auf Aktiviert gesetzt

    4. Speichern und neu starten


    Dann rödelt er mit schwarzen screen für 1-3 Minuten und auf einmal landet man in Windows. Da hilft keine Tastenkombi, der bootet einfach direkt durch.

    ---


    Ich raff es alles nicht. Das ist so eine verkorkste Sache mit diesen Gigabyte Board.


    Hier sind meine vollständigen Specs: https://pcpartpicker.com/b/KHPV3C

    Wenn EFI hilft pack ich das auch noch dazu.

  • Naja, du hältst es sehr schwammig, was genau die “funktionierende” Methode ist (was du mit deinem eigenen Schlüssel machst, taucht nicht auf). Den privaten Schlüssel brauchst du dafür nicht. Da ich nicht den ganzen Prozess verstehe, kann ich nur raten - vielleicht wird der GPU-Treiber nicht geladen, weil die generell mit dem Microsoft 3rd Party CA signiert sind (ebenso wie der Linux-Shim) und dieser Schlüssel nicht hinterlegt ist.

  • Grüß dich,


    Ich sag mal so, wenn man sich hier einmal an die Materie ranwagt merkt man, das sollte in der Theorie ganz simpel sein, scheint aber bei Gigabyte fürchterlich vergeigt zu sein.


    Habe da den Verdacht, das BIOS übernimmt diese Vendor Keys nicht sauber in den NVRAM oder die Einträge werden vorher nicht sauber aus dem NVRAM gelöscht. VBIOS Signatur im Zusammenspiel mit den PK/KEK/db keys scheint hier auch ein Thema zu sein, daher wohl auch der schwarze Bildschirm wenn es dann ab und zu mal klappt mit der "eingeschränkten" Secure Boot Methode, die einen direkt ins Windows wirft ohne Zugang zum BIOS. Es scheint auch nicht durchgängig zu funktionieren und ist jeweils immer ein zeitaufwendiger Prozess da man das BIOS komplett neu flashen muss nach jedem Versuch.


    Also ich habe folgende Ansätze probiert, jedes mal mit komplett Stock BIOS / CMOS Reset


    1: Secure Boot auf aus, Microsoft Keys im BIOS über 'Restore Factory Keys' geladen, Secure Boot Modus schaltet von Setup auf User, Secure Boot aktivieren, neustarten. Kein POST.

    2: Das BIOS bietet die Funktion 'Restore Factory Provision' - ähnlich wie Restore Factory Keys, aber wo zusätzlich noch NVRAM komplett geleert wird und ein extra Reboot gemacht wird, selbes Prozedere wie bei 1 und wieder: Kein POST.

    3: Dann kann man Custom Files über das BIOS Signen - prima dacht ich, signe ich mal alle OpenCore .efi Files die geladen werden. Kein POST.

    4: Dann kann man die Microsoft Zertifikate / Vendor Keys extern über Ubuntu mit den OpenCore .efi Files cross-signen, da wird openssl genutzt. Zuerst generiert man seine PK/KEK/db Keys und signed diese dann mit den Images und wirft die wieder zurück in die OpenCore EFI Partition. Aktiviere ich dann Secure Boot bleibt er erstmal im Setup Mode, schalte ich dann auf Custom bleib er im Custom Mode stecken weil ja keine Keys geladen werden. Also lade ich wieder die Vendor Keys und wieder kein POST.

    5: Dann gibt es die Methode wie bei 4, nur dass über das Keytool seine generierten PK/KEK/db Keys ins BIOS lädt, das klappt auch - man landet im Secure Boot User Mode aber im Anschluss wieder kein POST. Hier ist allerdings zu sagen, dass er hier AB UND ZU dann Secure Boot aktiviert hatte und man wieder ohne BIOS Zugang im Windows landet. Aber auch eher random.

    6: Vendor Keys im BIOS geladen und zusätzlcih meine KEK/db Signatur angehangen, wieder kein POST.


    Bin wirklich irgendwie mit dem Latein am Ende. :-D

  • Ich kenne die Anleitung, genauso signiere ich meine EFIs und mit meinem Lifebook funktioniert das wie es soll.

    Secureboot muss auf Custom (oder so) eingestellt sein und ausgeschaltet sein.


    Dann das Keytool booten (es reicht das KeyToool auf einen FAT32 Stick zu kopieren)

    ...und dan PK, KEK und db rein (die 3 auch auf den Stick packen)


    Danach Secure Boot im Bios einschalten.

    In der OpenCore Config darf SecureBootModel nicht auf Dsabled stehen, sonst bootet OC nicht!

    Files

    • Keytool.zip

      (704.34 kB, downloaded 46 times, last: )
  • Jo, hab ich gerade noch einmal versucht. Bleibt beim schwarzen Screen und kein POST. Hab mittlerweile die Vermutung dass die RX6800 GraKa da irgendwie Zicken macht, oder das echt einfach nur am Gigabyte BIOS liegt. Könnte mir mal ein gebrauchtes Z690 Board holen als Gegenversuch.

  • Okay, Problem gelöst. Das VBIOS der RX6800 war gepatched. Standard VBIOS raufgeflashed und schon geht alles. Meine Güte. :D

  • Oh, fein dass der Thread hier ist. Ich stehe grad... am selben "Battlefield" :-D


    Ich habe die github Anleitung klar, und soweit klappen 3/4 meiner Anforderungen:


    1. OpenCore kommt wieder mit Bootpicker,

    2. Windoofs bootet,

    3. Ubuntu bootet.


    jedoch 4. OSX - bootet nicht. Ich bekomme kurz einen grayscreen, dann springt er sofort zurück in den bootpicker. Keine Meldung.


    beim sign geht github im opencore nur von ein paar Driver efis aus - ich habe aber eine Menge mehr .efi files im Drivers Ordner. Ist das evtl. schon my fault? Müssen alle gesigned werden damit ich einen boot durch bekomme? (Bevor ich nun wild in den plists rumkrame...

  • SecureBootModel darf nicht Disabled gesetzt sein.

    Für Update muss man aber Disabled setzten - heißt dann also Secureboot im BIOS ausschalten

  • Gotcha! Ich hatte das Model tatsächlich auf Disabled stehen. Mist. OK. Ich bekomme nun wieder den Grundboot, habe aber Debug grad aus und laufe in eine Kernelpanic. Ich muss jetzt erstmal abgleichen was github in der plist für secureboot noch erwartet. Ich dachte ich habe alles drin ... öööhm. Wohl nicht. Hmmm, da sind wir wieder im Rabbit hole.