Note that checking anything in userspace on a compromised machine does not actually prove that the machine is not compromised. It is very easy to boot insecurely and then make everything lie that the boot was secure.
Assuming they're USB devices they shouldn't be a reason to do this... Apple moved third-party drivers for USB devices and audio HAL extensions to user space, so there's some minor overhead choosing DriverKit over IOKit. Everything I've dug up says it's low single digit percentages. I wouldn't be developing USB drivers against IOKit anymore personally and I'd be looking to move over pretty aggressively before Apple drops the hammer.
Not exactly, distribution conversation aside this is specific to kernel extensions. Apple's been moving drivers out of kernel space and into user space for several years [1]. There's a lot of good reasons for doing so, and not a lot of drawbacks. I'd consider this to be a strongly worded API deprecation notice.
You can run unverified code if you build it yourself. You can distribute unverified code by just paying $99/year to Apple. Not great, but still no need for specific code approval.
Not if you want to use some features like bridged networking. For that you need to go and beg Apple for an entitlement. Or you have to disable SIP entirely.
To be fair, they _do_ respond well in this particular case. But you have to write an email to a developer somewhere in Apple, as there is no established process.
Note that checking anything in userspace on a compromised machine does not actually prove that the machine is not compromised. It is very easy to boot insecurely and then make everything lie that the boot was secure.
I had to do this today for a Universal Audio Apollo audio interface. Glad it’s on a dedicated machine.
https://help.uaudio.com/hc/en-us/articles/360057137692-Apple...
Interesting. They need that for lowest-possible latency? And it should be fairly safe?
Assuming they're USB devices they shouldn't be a reason to do this... Apple moved third-party drivers for USB devices and audio HAL extensions to user space, so there's some minor overhead choosing DriverKit over IOKit. Everything I've dug up says it's low single digit percentages. I wouldn't be developing USB drivers against IOKit anymore personally and I'd be looking to move over pretty aggressively before Apple drops the hammer.
How about file system drivers? If there is such a thing any more... fuse and friends...
UAD drivers have always been very creative... lol
s/booting securely/running only the code Apple approves of/g
Not exactly, distribution conversation aside this is specific to kernel extensions. Apple's been moving drivers out of kernel space and into user space for several years [1]. There's a lot of good reasons for doing so, and not a lot of drawbacks. I'd consider this to be a strongly worded API deprecation notice.
[1] https://developer.apple.com/documentation/driverkit
You can run unverified code if you build it yourself. You can distribute unverified code by just paying $99/year to Apple. Not great, but still no need for specific code approval.
You can run whatever scripts you want without paying anything. Pretty sure the signing thing only applies to .app programs.
Not if you want to use some features like bridged networking. For that you need to go and beg Apple for an entitlement. Or you have to disable SIP entirely.
They respond to the begging as incredibly well as they respond to feedback/bug reports, right?
To be fair, they _do_ respond well in this particular case. But you have to write an email to a developer somewhere in Apple, as there is no established process.
Useful, thank you! Looks like the author just enjoys helping fellow nerds. Nice
Dr Howard Oakley. I think of him as an OG Mac guy.
`man csrutil`