Cargar una extensión del kernel que no es de confianza en macOS Mojave

El Volta La aplicación está instalada en mi MacBook Pro, con MacOS 10.14 Mojave.

Esta aplicación necesita una extensión del kernel para funcionar correctamente, y dicha extensión no tiene las firmas de código adecuadas. Esto significa que es necesario manipular la protección de integridad del sistema para cargar esta extensión.

En MacOS 10.13 High Sierra, se puede ejecutar csrutil enable --without kext para desactivar parcialmente el SIP (se permite la carga de kexts sin firma, pero se mantienen otras protecciones). Según el informe de Volta instrucciones de instalación En Mojave hay que desactivar totalmente el SIP, dejando todo el ordenador desprotegido por una extensión del kernel.

Como referencia, esta es la salida de kextutil -l aplicada a esta extensión:

$ sudo kextutil -l /Applications/Volta.app/Contents/Resources/Driver.kext
Untrusted kexts are not allowed
Kext with invalid signature (-67050) denied: /Library/StagedExtensions/Applications/Volta.app/Contents/Resources/0A012E5A-9F74-4E19-9195-535AD692A597.kext
Bundle (/Applications/Volta.app/Contents/Resources/Driver.kext) failed to validate, deleting: /Library/StagedExtensions/Applications/Volta.app/Contents/Resources/0A012E5A-9F74-4E19-9195-535AD692A597.kext
Unable to stage kext (/Applications/Volta.app/Contents/Resources/Driver.kext) to secure location.

Y este es el resultado de ejecutar codesign --display --verbose=4 /Applications/Volta.app/Contents/Resources/Driver.kext como se sugiere en Respuesta de Ricardo Anjos :

Executable=/Applications/Volta.app/Contents/Resources/Driver.kext/Contents/MacOS/Driver
Identifier=com.gmathews.volta.driver
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=345 flags=0x0(none) hashes=3+5 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=cbf1caa72d5071c35aa3c020d557a084e6e5a8c9
CandidateCDHash sha256=468cc8b2215b53445cb650c94a76413db62a4815
Hash choices=sha1,sha256
Page size=4096
CDHash=468cc8b2215b53445cb650c94a76413db62a4815
Signature size=4697
Authority=Developer ID Application: Gary Mathews (SFS8238QUB)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=26 Jul 2018 23:14:21
Info.plist entries=19
TeamIdentifier=SFS8238QUB
Sealed Resources version=2 rules=13 files=0
Internal requirements count=1 size=220

Aquí está también la salida para codesign -v en el mismo archivo:

/Applications/Volta.app/Contents/Resources/Driver.kext/Contents/MacOS/Driver: valid on disk
/Applications/Volta.app/Contents/Resources/Driver.kext/Contents/MacOS/Driver: satisfies its Designated Requirement

También seguí el mismo proceso con el ejecutable principal así como con la aplicación de ayuda, y todos se verificaron (firmas válidas, y la misma autoridad e ID de equipo).

He comparado la salida de codesign a otro kext aleatorio de terceros en mi ordenador, que funciona bien sin necesidad de sortear el SIP, y no pude detectar ninguna diferencia.

Además, Página de preguntas frecuentes de Volta instruye al usuario sobre cómo trabajar alrededor de SIP, por lo que parece una decisión deliberada del desarrollador y no sólo un error.

Me molesta mucho esta situación. Como propietario legítimo de esta máquina, y teniendo acceso físico a ella, ¿no hay nada que pueda hacer (aparte de desactivar completamente el SIP) para poner en la lista blanca esta extensión del kernel, suponiendo que el desarrollador no pueda firmar la extensión por alguna razón? No me importa si hay que introducir comandos crípticos en el modo de recuperación, escribir cosas en la NVRAM o firmar el código de la extensión yo mismo, siempre y cuando no tenga que pagar a Apple 99 dólares por el privilegio.