On OS X Intel the operating system will basically refuse to run unsigned code unless you know an ever-shifting series of magic undocumented cheat codes. You have to do weird things like hold down certain keys then use the right click context menu to open unsigned apps, you need magic CLI commands to disable notarization checking, you have to go into the system preferences window to enable drivers to be approved and then reboot etc. The UX is atrocious and gets worse all the time - it's barely acceptable even for developers. That's for usermode. Kernel mode drivers are dead now, more or less.
On OS X ARM unsigned code will not run. Period, end of story. The magic cheat codes are gone. All code must be notarized, which is a server-side approval process of the type Microsoft only use for kernel drivers.
There are a few silver linings to all this. One is that getting a cert isn't actually that hard. You need a credit card, basically. It's not like getting an EV cert where you need a company and for a CA to verify the corporate identity. Likewise their "notarization" process is not a manual app store like review, it's fully automated and is mostly just checking that the app is well structured and properly signed. It probably does other things like checking you aren't using internal APIs, and they presumably archive all the binaries they notarize so they can go back in time to investigate malware and so on. But it's not being used for political or commercial purposes, at this time.
- SIP off (totally, or just driver signature enforcement)
- kernel driver (deprecated, Apple doesn’t issue new certs anymore it seems)
- system extension (user-mode driver, explicitly intended for device compatibility)
(no idea how this actually works in practice, wonder if one could wrap open source work under a non-profit organization)
1) Test signing - do what you want
2) Kernel driver - still possible, needs EV cert?
For 2), it’s borderline impossible to get a driver signing cert for macOS nowadays for individuals, it’s easier on Windows.
This is not true. kexts are still signed by apple after being submitted and vetted.
The net effect of this: if something can be done using a System Extension rather than a kernel extension, you'll get deprecation warnings if you try to do it with a kernel extension. Kernel extension points that have not been replaced yet are still valid, will still be signed if used, and will still run on current versions of macOS.
And presumably on OSX none of this applies because it's all BSD underneath? Or is OSX different again to just running BSD out of the box?