Funktionierender NVRAM nun mit Clover

Funktioniert eben getestet. Ein großes an vit9696 und @Download-Fritz.

Der Fix ist übrigens auch in der aktuellen Version Clover_v2.4k_r4369 enthalten. Funktioniert bei mir, besten Dank an @vit9696, @Download-Fritz, @MacGrummel und @hitman20.

Zitat von hitman20

Dies soll aber erst ab Skylake funktionieren.

Eigentlich ab Haswell-E, alles vorher sollte schon funktioniert haben.

Ich entwickle nicht, ich teste und schreibe nur..
Vielen Dank an die Entwickler, wieder ein gutes Stück Arbeit!

Cool Funktioniert tatsächlich.

Test mit Variable schreiben:

Ist nach Neustart wieder Verfügbarer mit

Ich habe die aktuelle Clover-Version mal auf meinem Lenovo E460 getestet und endlich überlebt die Einstellung für die Bildschirmhelligkeit wieder einen Neustart. Sehr schön!

Das heisst der EmuVariableUefi-64 und die RC-Scripte sind damit hinfällig?
Cool!!!!

RC-Scripte, guter Hinweis. Werden die gelöscht, wenn man das im Clover-Installer abwählt?

Kann ich nicht sagen, ich habe die Änderungen eben manuell durchgezogen, da ich Clover bereits heute Mittag aktualisiert habe.
Die Scripte liegen unter /etc/rc.boot.d und /etc/rc.shutdown.d...
Einfach beide Ordner entfernen und die Datei nvram.plist auf der versteckten EFI-Partition, zusammen mit der /EFI/CLOVER/drivers64UEFI/EmuVariableUefi-64.efi löschen.

Kann für beide Systeme eine positive Rückmeldung geben... funzt...

Tolle Arbeit der Entwickler...

Nein, werden nicht gelöscht. Liegen auf der Mac-Platte in /etc/rc.boot.d/ und /etc/rc.shutdown.d/

EDIT: der @al6042 war schneller.

Bei mir auch. Funktioniert auch auf beiden Systemen.

Top! Funktioniert auch auf meine Lenovo E560!

Der Fix killt bei mir den Zugriff auf die EFI Runtime Services.
Zugriff erfolgt über AppleEFIRuntime und funktioniert mit den alten OsxAptio einwandfrei.
Die neuen crashen mit schwarzem Schirm und Neustart.
Kennt jemand eine Abhilfe, außer die alten zu weiter verwenden ?

Oh weh...
habe ich bisher nicht erfahren müssen...
Läuft bei mir...

Der einzige Fix bei mir ist der Holzhammer-OsxAptioFix2Drv-free2000.efi. Und so hab ich dann doch nichts gewonnen..

Zitat von Brumbaer

Der Fix killt bei mir den Zugriff auf die EFI Runtime Services.
Zugriff erfolgt über AppleEFIRuntime und funktioniert mit den alten OsxAptio einwandfrei.
Die neuen crashen mit schwarzem Schirm und Neustart.
Kennt jemand eine Abhilfe, außer die alten zu weiter verwenden ?

Woher weißt das, wird doch irgendetwas angezeigt? Wenn ja, Bild/Dump/whatever bitte.

Ich habe eine App, die EFI Runtime Service Routinen aufruft.

Dazu spricht sie mit dem User Client eines Treibers, dessen Provider AppleEFIRuntime ist und über AppleEFIRuntime erfolgt der Aufruf der EFI Runtime Service Routinen.

Das funktioniert auch wunderbar, solange das System mit einem "alten" OSAptioFixDrv gebootet wird.

Wird hingegen der neue OSAptioFixDrv verwendet, wird der Bildschirm schwarz und es wird neu gebootet.

AppleEFIRuntime führt den Aufruf aus der EFI Runtime Service Tabelle nicht selbst aus, sondern verwendet dazu _pal_efi_call_in_64bit_mode. Das stammt steht wohl aus com.apple.kpi.private.

Ob AppleEFINVRam den Provider für die Zugriffe aufs NVRam benutzt, erschließt sich mir nicht auf den ersten Blick. Ich bin mir nicht sicher ob überhaupt irgendeine Software AppleEFIRuntime zur Laufzeit aufruft.

Ja, NVRAM nutzt AppleEFIRuntime. Welche funktion ruft die App auf?

EDIT: Nach 'nem normalen Boot oder nach S4-Wake?

EDIT2: Ich gehe einfach mal davon aus, dass es eine Variable-Funktion ist, die wir nicht überschreiben... also, das Problem ist, dass ein Teil des AMI-Flash-Treibers vom NVRAM-SMM-Treiber beschrieben wird. Mit dem alten AptioFix wurde diese Speicheradresse physisch verschoben und natürlich auch woanders gemappt, weswegen der NVRAM-Treiber dann fröhlich ins Nirvana schreibt, was zufälligerweise in einem R/W-Speicherteil erfolgt. Mit dem neuen AptioFix wird das physische Verschieben verhindert und der SMM-Treiber schreibt in einen eigentlich R/O-Bereich, was zu einem GPF-KP führt. Deshalb wurden die drei Variable-Funktionen, GetVariable, SetVariable und GetNextVariableName überschrieben, um beim Aufruf das WP-Bit aus dem CR0 rauszuhauen, was den KP verhindert. Wenn du eine andere, nicht überschriebene Funktion aufrufst, führt das erwartungsgemäß zu einem KP.
Die Entscheidung, nur diese drei zu überschreiben, war strategisch, da macOS nur diese drei Var-Funktionen nutzt. Das WP-Bit ist leider Core- und nicht Thread-bezogen, deshalb kann ohne einen Spinlock, wie AppleEFIRuntime ihn setzt, der zweite Thread im Kern auf XNU-Ebene in R/O-Speicher schreiben. Wenn eine Kext also einen Bug oder was auch immer hat, dass sie out-of-bound schreibt und zufällig der andere Thread gerade einen RT-Dienst mit dem WP-Code ohne Spinlock (also an AppleEFIRuntime vorbei) aufruft, wird das WP-Bit rausgekickt und die Kext schreibt erfolgreich ins Nirvana.
Deswegen: Seit wann gibt es dieses User-Client-Interface für AppleEFIRuntime? Mir wurde gesagt, dass es sowas nicht gibt... mit der Nutzung von diesem gibt es keinen Grund, einen RT-Dienst direkt aufzurufen und das obige Problem ist gelöst.

Ich hab beim Start an meinem X99er diese beiden Standart-Meldungen, zuerst konnte ich normal starten, dann hab ich zum testen die EFI gewechselt, danach dann das hier:


Zwischendurch gab's noch andere Meldungen, dafür war die Kamera aber nicht schnell genug zur Hand. Versuch ich gleich noch einmal!