Setup & Software Discussions
End of an Era - Demise of Kext Patching on macOS
 

End of an Era - Demise of Kext Patching on macOS  

  RSS

mac_editor
(@mac_editor)
Famed Member Moderator
Joined: 3 years ago
 

Important update for Mac users on older devices and users of NVIDIA eGPUs.

With macOS Catalina, Apple has introduced multiple filesystem changes. An upgrade to Catalina creates a new volume reserved only for system components. In the early developer beta, this volume has read-write access. However, future seeds will make the System Volume a read-only filesystem. There is also a way to test read-only behavior on early betas, which I have done, before posting this. In this state, it is theoretically impossible to patch kernel extensions on disk, which means the end of scripts such as purge-wrangler and purge-nvda (hint: not exactly, read on), and potentially difficult via EFI (read further about kexts).

@goalque's automate-eGPU EFI should (haven't tested myself - will report soon) remain functional as long as kexts are employed in the system in the usual manner. Creating a kext-based override would work, until Apple deprecates kexts with the new DriverKit and SystemExtensions system. However, it is clear what the future holds. I believe that even EFI patching in general will become a challenge in later years as Apple shifts silicon (custom chips, etc.) and enforces more security at the core of the system. I don't generally disagree on Apple's position on security and privacy, so I am not complaining.

With that in mind, all I can say is that we as a community should aim to provide system patches until a newer version of macOS supports only Thunderbolt 3 or later devices, or until Apple closes all known avenues of patching mechanisms - whichever happens first. It is difficult to make a case to support NVIDIA GPUs, given how we were left in the dust in Mojave already. Of course, there may be someone out there who finds yet another mechanism to bypass this, but only time will tell. 

So now about that hint: Even on release versions of Catalina, it will be possible to mount the System Volume as a read-writable system, perform the patches, and then rebooting would restore the read-only property of the volume. But how long will this be true? I need to learn more about this - will update here if I do.

Update (June 7, 2019): It would seem that macOS Catalina may be the last release to support kexts without compromises - which would also impact Clover patching mechanisms used in automate-eGPU EFI.

This topic was modified 6 months ago

purge-wranglerpurge-nvdaset-eGPU
Insights Into macOS Video Editing Performance (Coming Soon)
2018 MacBook Pro 15" RP560X + RX 5700 XT (Mantiz Venus)


ReplyQuote
goalque
(@goalque)
Noble Member Admin
Joined: 3 years ago
 

It was mentioned in the WWDC sessions that macOS 10.15 will be the last release to fully support kexts without compromises. After that, Apple gradually adds more DriverKit device families, and kexts for the device families will not load in future releases. So even if you found a workaround, it would be useless in macOS 10.15.1 and later.

I suppose that Clover based EFI patches will not work either because kexts do not exist after 10.15. The first release of Catalina supports only USB, Serial, NIC and HID in IOKit. IOPCIDevice replacement was not mentioned so Nvidia can't start developing GPU drivers, and due to App integration, system-wide extensions won't be possible anymore. No such thing as a "standalone system extension".

The SIP already did the job well and protected system files. It seems that you can't be a real Unix-like admin of the Apple system even if you would like.

This post was modified 6 months ago

automate-eGPU EFIapple_set_os.efi
--
2018 13" MacBook Pro + Radeon [email protected] + Win10 1809


ReplyQuote
mac_editor
(@mac_editor)
Famed Member Moderator
Joined: 3 years ago
 
Posted by: goalque

It was mentioned in the WWDC sessions that macOS 10.15 will be the last release to fully support kexts without compromises.

@goalque I thought they said something like kexts would be deprecated sometime in a future release of macOS (unspecified) - must have missed this or don't remember this line. Thanks for bringing it up. Will update main post.

IOPCIDevice replacement was not mentioned so Nvidia can't start developing GPU drivers, and due to App integration, system-wide extensions won't be possible anymore. No such thing as a "standalone system extension".

Yes noticed that. Will be interesting to see how things pan out over this release.

This post was modified 6 months ago

purge-wranglerpurge-nvdaset-eGPU
Insights Into macOS Video Editing Performance (Coming Soon)
2018 MacBook Pro 15" RP560X + RX 5700 XT (Mantiz Venus)


goalque liked
ReplyQuote
goalque
(@goalque)
Noble Member Admin
Joined: 3 years ago
 
Posted by: mac_editor
Posted by: goalque

It was mentioned in the WWDC sessions that macOS 10.15 will be the last release to fully support kexts without compromises.

@goalque I thought they said something like kexts would be deprecated sometime in a future release of macOS (unspecified) - must have missed this or don't remember this line. Thanks for bringing it up. Will update main post.

Concluded from this slide

EDIT: Not sure if "a future release of macOS" means 10.15.1, 10.16, or something in between.

This post was modified 6 months ago

automate-eGPU EFIapple_set_os.efi
--
2018 13" MacBook Pro + Radeon [email protected] + Win10 1809


ReplyQuote
John Keates
(@oneplane)
Active Member
Joined: 1 year ago
 

Seems to be a deprecation of kexts that can be implemented using sexts (system extensions, I guess this is why they don't use the shorthand for that like with kernel extensions).

"In future releases of macOS kernel extensions of this kind will not load" means: if you have a different kind it will still work. Then again, that still excludes patched extensions and depending on what 'kinds' they have at that point, maybe the type of extensions we currently expect won't exist at all.

On the other hand, as posted in the first post: this is as annoying as it is good; there should really be no reason for mess with a system at runtime. The purpose of the system is to serve a known foundation, and a foundation only works well (in terms of security, stability etc.) if you can't mess with it. This is happening at more scopes, like by-system, by-device but also by-cloud context; the idea of having an immutable infrastructure makes for a somewhat immune infrastructure, which is a good thing.
 
Let's hope we can find a way to still do what we (the non-user users) want to do differently. If not, so be it, I can't really complain seeing what I get back for it.

rMBP 2015 13", AkiTiO Node, RX 570 4GB, 10.14 + Win10, Apple TB2-TB3


itsage liked
ReplyQuote
mac_editor
(@mac_editor)
Famed Member Moderator
Joined: 3 years ago
 

@oneplane they are using dexts though as a shorthand for driver extensions though haha.

Yes, I noticed that statement in the session as well. Perhaps it is worth thinking about the fact that the system volume won’t always be immutable given that it would be touched in software updates - so a configuration/situation does exist where it will be mutable. I recall one of the sessions mentioning that after disabling SIP, one boot would lead to a mutable system volume - restoring to normal on next boot - and that we can do this again and again (painstaking though it may be), though SIP itself is a persistent change (does this imply one recovery boot -> one read-write system volume normal boot? Could be anything at this point or even the csrutil tool). So the avenue of patching system components is still possible. Thus am looking forward to testing a future seed which enables read-only volumes by default.

purge-wranglerpurge-nvdaset-eGPU
Insights Into macOS Video Editing Performance (Coming Soon)
2018 MacBook Pro 15" RP560X + RX 5700 XT (Mantiz Venus)


ReplyQuote
John Keates
(@oneplane)
Active Member
Joined: 1 year ago
 

They probably have a communication channel (either a nvram mailbox type, or a T2 XPC/IPC message) used to signal a boot override for system updates, they use something similar on iOS devices (which is what looks like the inspiration for the macOS version of immutable systems).

I'm imaging something like a combo between fdesetup's authrestart, a nvram parameter change and (when installed) a T1/T2/Tx message to enable system volume changes from the system volume itself. In-situ updates would make the whole immutability point moot, but the reboot-before-it-works mode makes sense.

Let's see what happens in the coming months. I got the macOS 10.15 beta message today, but I'm not really going to do any updates until some more success stories for TB2 macs with purge-wrangler appear 😉

rMBP 2015 13", AkiTiO Node, RX 570 4GB, 10.14 + Win10, Apple TB2-TB3


ReplyQuote
mac_editor
(@mac_editor)
Famed Member Moderator
Joined: 3 years ago
 

@oneplane Those are certainly some of the possibilities, but I doubt it would rely on the T2 given that the OS is supported on a majority of non-T2 Macs (including 2019 iMac). NVRAM could be an option, but that would just be security by obscurity (we would need to know the right key-value pair really) - not a good approach IMO. The reboot-before-read-write system is perhaps a good clue as to how the update process would go: read-only -> updates set up their files on data drive -> proprietary modification for next boot -> apply patch to system volume -> remove modification -> read-only. Another clue is the read-write boot after disabling SIP (a persistent config. value) - per the WWDC sessions. Guess we will find out in the next few seeds - hopefully this is mentioned appropriately in release notes.

Yes, it seems best to stick with Mojave if you have a TB2 or older Mac. I guess I'll be adding a permissions/writability check to purge-wrangler soon haha (done :p - for a future big release).

This post was modified 6 months ago

purge-wranglerpurge-nvdaset-eGPU
Insights Into macOS Video Editing Performance (Coming Soon)
2018 MacBook Pro 15" RP560X + RX 5700 XT (Mantiz Venus)


ReplyQuote
goalque
(@goalque)
Noble Member Admin
Joined: 3 years ago
 
Posted by: oneplane

Seems to be a deprecation of kexts that can be implemented using sexts (system extensions, I guess this is why they don't use the shorthand for that like with kernel extensions).

"In future releases of macOS kernel extensions of this kind will not load" means: if you have a different kind it will still work. Then again, that still excludes patched extensions and depending on what 'kinds' they have at that point, maybe the type of extensions we currently expect won't exist at all.

On the next slide he said "more kinds of System Extensions" and "more DriverKit device families" will be added and "kernel extensions of those kinds will also be deprecated". Deprecated does not mean immediate removal but likely soon because the time to act is now:

"Is there any ETA on when it will be removed?
No.
However, the time to act is now. If you delay you run the risk of discovering that our user space support doesn’t contain the features you need too late for us to help you out."

https://forums.developer.apple.com/thread/117377

I was a bit confused about the "no standalone system extension". When I watched the video again, there is a clear separation between the DriverKit Driver (or Driver Extension, dext) and System Extension (.systemextension), though it was also said that Driver Extension is one of the three System Extension types, and generally, "System Extension" is always part of an app.

In the case of dext it does not seem to be embedded into the app (located in /System/Library/DriverExtensions folder) but maybe can be considered as an app because each device attached to the system creates a new process instance?

I also found that IOPCIDevice class is already specified in the DriverKit: https://developer.apple.com/documentation/driverkit/iopcidevice?language=objc

This post was modified 6 months ago

automate-eGPU EFIapple_set_os.efi
--
2018 13" MacBook Pro + Radeon [email protected] + Win10 1809


ReplyQuote