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.
Recovery exists in a separate partition protected by SIP; it's set up this way to so that 99.99% of scenarios require a local, physical attack. "recoveryOS" is also bound to the specific APFS volume of the device. There's more to it than that, but you can be reasonably sure that recoveryOS isn't lying to you.
Sure, you can make an argument someone gave you a special device with a fake OS... but anyone willing to do that has much more simple ways to fuck with you.
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.
> macFUSE 5.0 supports multiple APIs for mounting file systems.
> By default, macFUSE uses the VFS API to mount file systems. When specifying the mount-time option -o backend=fskit, macFUSE will use FSKit to mount the file system.
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.
Recovery exists in a separate partition protected by SIP; it's set up this way to so that 99.99% of scenarios require a local, physical attack. "recoveryOS" is also bound to the specific APFS volume of the device. There's more to it than that, but you can be reasonably sure that recoveryOS isn't lying to you.
Sure, you can make an argument someone gave you a special device with a fake OS... but anyone willing to do that has much more simple ways to fuck with you.
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...
There is a port of FUSE for macOS, and Apple also has a first party API for this called FSKit…
https://developer.apple.com/documentation/fskit
I know there was a port of FUSE. But iirc it requires old style extensions. Has it changed?
Per the MacFUSE documentation…
> macFUSE 5.0 supports multiple APIs for mounting file systems.
> By default, macFUSE uses the VFS API to mount file systems. When specifying the mount-time option -o backend=fskit, macFUSE will use FSKit to mount the file system.
https://github.com/macfuse/macfuse/wiki/FUSE-Backends
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.
His site is filled with gems like this one.
The problem is if you enable filevault then you can’t ssh into the mac remotely until someone locally logs in.
Means I end up using filevault on my laptop, but not on my desktop.
`man csrutil`