Beiträge von talkinghead

    falls ich dein Anliegen richtig verstehe... ich hab das bei mir über Einträge in der Datei /etc/fstab gelöst

    entscheidend ist "noauto".

    Die UUID (Volume UUID) bekommt du mittels

    Code
    1. diskutil info -all

    das Filesystem ist entweder ntfs bzw msdos für die EFI Partition von Windows.

    Ich finde HDMI überflüssig, zumal es bereits einen Port, der die Funktion bereits abdeckt.

    Das mit HDMI hat mich zuerst auch sehr gewundert. Allerdings ist es mir auch schon passiert, dass ich mit meinem MBP irgendwo war, sollte was auf den TV werfen. HDMI Eingänge haben m.E. alle neueren Geräte. Ohne Adapter oder Airplay geht das schlecht. In Unternehmen stehen sehr häufig HDMI-fähige Beamer. Machmal auch kabellose Lösungen aber eher selten. Ich kenn den Stress, wenn man was zeigen will, aber kein Connect herstellen kann.

    griven die Karte läuft im Dualboot mit Windows 11 - je gebootet unter Windows sofort. Ich konnte dazu auch zwischen Beta 8 und 9 hin und her installieren. Unter 8 geht, ab 9 nicht, wiederholbar.


    Spannend finde ich zudem, dass mein Switch sogar manuelle Änderungen des Speed und Duplex sieht. Die Karte tut also mit dem Treiber Dinge, nur wird das Medium nicht sauber erkannt.

    Falls Du noch einen PCIE-Steckplatz frei hast....ich hab das mit dem Realtektreiber frühzeitig wg Sleep /IP renew / IPV6 Problemen aufgegeben und hab ne Intel NIC drin. Die läuft nach Patching der ID mit den nativen Treiber. Aus Intel CT Desktop Adapter eine Apple NIC machen. Zusammen mit ner Fenvi 1200 läuft das total problemlos.

    Die Onboard Karte nutze ich ausschließlich unter Win. Dort hab ich die Intel Karte deaktiviert.

    OT: ich verstehe noch nicht genau, wie trim unter Windows getriggert wird. Durchgeführt wird das über defrag.exe. Der Schalter "-o" bedeutet: "Führt für jeden Medientyp die richtige Optimierung durch."


    In meinem WD Tool gibt es Trim Settings speziell für meine einzige WD disk. Nachdem ich Täglich aktivert hab, gibts im Win Taskplanner einen neuen Task mit diese Aktion: defrag.exe f: -O -H. "-O" ist optimize.

    BTW: Der Haken oben bei "Windows Trim aktivieren" war an, aber bei "Zuletzt ausgeführt" stand "Nie". Erst als ich auf den Button obendrüber geklickt hab, war fast sofort die aktuelle Zeit drin.



    apfelnico : Theoretisch könnte das also auch pro Disk/Volume gehen. Praktisch ist es wahrscheinlich unter macOS so nicht implementiert.

    Moin,

    für UEFI Secure Boot fehlten mir noch die passende sbsign binary für macOS. Das signieren auf einer separaten Plattform war mir zu umständlich.

    In diesem GitHub Repo https://github.com/th0u/sbsigntools-macOS hab ich eine unter macOS kompilierbare Version abgelegt.

    Die Quellen sind unmodifiziert. Lediglich die Makefile-Templates wurden leicht angepasst und die Header-Files von gnu-efi wurden integriert.


    Ich nutze zum Kompilieren ein MacPorts Environment.

    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.

    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.

    Hier gehts zu Teil1 SECURE BOOT - WINDOWS 11 UND Monterey (DUALBOOT MIT OPENCORE) Teil 1


    Variante2: Eigenes Zertifikat erstellen, im Bios einspielen und Bootloader damit signieren.



    ***Achtung*** an dieser Stelle im Bios liegen voreingespielte Herstellerzertifikate. Ich übernehme keine Verantwortung dafür falls durch die folgenden Schritte Information gelöscht werden oder andere Betriebssysteme nicht mehr starten.



    Für diese Variante habe ich Informationen aus diesen Quellen verwendet

    http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html

    https://github.com/dortania/Op…ecurity/uefisecureboot.md


    In dieser Variante erstelle ich mir ein Zertifikat mit einer Laufzeit von 3650 Tagen.

    openssl req -new -x509 -newkey rsa:2048 -subj "/CN=Your Secure Boot key set DB/" -keyout DB.key -out DB.crt -days 3650 -nodes -sha256


    Wir erhalten zwei Dateien DB.key (privater Schlüssel) und DB.crt (öffentlicher Schlüssel)


    Das Bios erwartet den öffentlichen Schlüssel im DER-Format, daher konvertieren wir die crt-Datei zusätzlich noch in eine der-Datei.

    openssl x509 -outform der -in DB.crt -out DB.der


    Jetzt haben wir drei Dateien: DB.key, DB.crt und DB.der


    Der öffentliche Schlüssel im der-Format (der-datei) wird später im Bios in die Authorized Signature Database (db) eingespielt. Damit kann im Secure Boot Prozess überprüft werden, ob unsere selbssignierten Bootfiles mit unserem privaten Schlüssel (key-File) signiert wurde. Dazu kopieren wir die DER-Datei auf einen FAT-Formatieren USB Stick, den wir später für den Key-import in das Bios benötigen.


    Signieren der OC-Dateien:

    Für das Signieren der OC-Dateien orientiere ich mich am Inhalt von uefisecureboot.md (s.o.)

    Legt euch einen leeren Ordner “secureboot”

    In den Ordner secureboot kopiert ihr folgende Dateien:

    • DB.key
    • DB.crt
    • BOOTx64.efi(aus EFI/BOOT/)
    • OpenCore.efi(aus EFI/OC/)
    • OpenRuntime.efi(aus EFI/OC/Drivers/)
    • HfsPlus.efi (aus EFI/OC/Drivers/) wobei ich nicht sicher bin ob HfsPlus.efi signiert werden muss
    • signed (Legt hier noch den Ordner “signed” an)


    In der CLI wechselt in den Ordner secureboot und führt folgende Commands aus (sbsign solltet ihr irgendwo im Pfad halten)

    sbsign --key DB.key --cert DB.crt --output signed/BOOTx64.efi BOOTx64.efi

    sbsign --key DB.key --cert DB.crt --output signed/OpenCore.efi OpenCore.efi

    sbsign --key DB.key --cert DB.crt --output signed/OpenRuntime.efi OpenRuntime.efi

    sbsign --key DB.key --cert DB.crt --output signed/HfsPlus.efi.efi HfsPlus.efi


    Anschließend solltet ihr im Ordner “signed” die 4 signierten EFIs finden.

    Info: das sbsign-Tool wirft bei mir warnings aus. Prinzipiell besteht die Möglichkeit, dass die Binaries einen Schaden haben. Ich habe aber bisher nichts negatives feststellen können. Mit den warnings werde ich mich später noch befassen.


    Nachdem ihr die 4 OC Dateien signiert habt, solltet ihr ein Backup des EFI-Ordners anlegen und dann die signierten efi-Files an ihren Platz im EFI Ordner über die unsignierten Versionen kopieren.


    Den Signiervorgang müsst ihr immer dann wiederholen, wenn ihr neue Binaries einspielt. Denkt auch an eure USB-EFI Boot Sticks (wobei man hier temporär Secure Boot deaktivieren kann).


    Falls ihr auch reFind benutzt, dann könnt ihr den auch mit sbsign signieren und in die reFind-EFI-Partition einspielen.


    Nachdem nun die Binaries alle signiert sind, muss noch der öffentliche Schlüssel ins Bios rein.


    Einspielen von DER-Datei ins Bios:

    Ins Bios gehen und USB Stick anstecken.

    Im Bios -> Boot -> Secure Boot -> Key Management -> Authorized Signatures -> Append -> “No” load it from a file -> DB.der -> Public Key Certificate -> Yes -> OK (Success).



    (Der Eintrag #3 ist mein oben erstellter Public Key)


    Anschließend könnt ihr nochmals in Authorized Signatures gehen und über Details den Inhalt anzeigen. Ihr solltet nun zusätzlich euer Zertifikat sehen.

    Info: Ich hatte durch das EFI Enrollment bereits zusätzliche Einträge in Authorized Keys und ein “Append” der DER-Datei war nicht auf Anhieb möglich. Ich musste dort erst alle meine hinzugefügten Hashes löschen, bevor “Append” möglich war.


    Bevor ihr das Bios verlasst, schaltet Secure Boot ein und speichert beim Verlassen.


    Wenn alles geklappt hat, könnt ihr OC booten und anschließend den Start von Windows testen.


    Troubleshooting:




    In meinen Tests lief alles rund. Es kann aber dennoch sein dass ich in der Doku oder ihr beim Durcharbeiten was übersehen habt.


    • Prüft ob Secure Boot aktiviert ist
    • Prüft ob ihr ohne Secure Boot booten könnt.
    • Prüft ob im authorized Signatures euer Zertifikat drin ist
    • Prüft ob ihr mit Enroll EFI Image und Secure Boot = on booten könnt
    • Prüft, ob ihr die Binaries korrekt signiert habt.






    (Bilder folgen)

    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

    Danke für den Tipp bzgl. Abhängigkeit von Win11/OC/SecureBoot.

    Ich hab mich gewundert, warum mein Win10 kein Win11 Update anbietet. Da hab ich kurzerhand im Bios auf Secure Boot gestellt. Win10 startete danach noch, OC und reFind nicht. Dafür wurde mit via Windows Update Win11 angeboten.

    Jetzt hab im Bios einen Eintrag gefunden, worüber man EFIs enrollen kann (mit dem Bios Key).

    Das hab ich für reFind und OpenCore.efi und OpenRuntime.Efi gemacht. Danach konnte ich mit "Bios SecureBoot=on" mein reFind, OC/Monterey und Win10 starten.


    Korrektur: Win11 wir via Windows Update nicht angeboten. Es steht jetzt da dass mein System die Mindestanforderungen erfüllt und der Download später verfügbar sein wird. Das stand vorher (ohne SecureBoot) nicht da.

    Jetzt warte ich mal ab und schaue, was SecureBoot=On alles so für Herausforderungen bietet (OC Update, OS Update etc)

    Der Crash ist mit B9 verschwunden.