Do System Extensions mean that KEXT will be deprecated?

I've just read about System Extensions and DriverKit, and it's unclear to me - does this mean that KEXT will be deprecated?

Yes.

If so, how soon will it happen?

That’s a complex question. The basic idea is that, as we introduce new user space functionality, we will deprecate the corresponding type of KEXT. For example, this year we’re introducing a wealth of new NetworkExtension features, and we’re deprecating NKEs. Similarly, for various I/O Kit families, kauth, and so on. However, there are still KEXT types that have no user space equivalent — the ones that immediately spring to mind are the remaining I/O Kit families and VFS plug-ins — and in that case the equivalent KEXT functionality is not deprecated.

I should stress that deprecated does not mean removed. To continue the example above, NKEs still function on 10.15. However, I would not expect that to continue for long. If you’re creating a KEXT for one of the subsystems which have user space replacements, the time to act is now.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi Quinn, thank you for the answer!

> I should stress that deprecated does not mean removed. To continue the example above, NKEs still function on 10.15. However, I would not expect that to continue for long. If you’re creating a KEXT for one of the subsystems which have user space replacements, the time to act is now.

Huh, got it. Is there any ETA on when it will be removed? Is it possible that it will be removed in some 10.15.X version?

They'll probably be removed in 10.16 or 10.17... Apple will probably give us a hard warning in 10.16..

^ is what I understand as future mac os versions

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.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

The main problem is not probably with the user space APIs. It's with the way system extensions are embedded and the quite unfriendly user experience to enable them.

I had a quick look at the demo of session 714 and it's quite user unfriendly:

- You have to go through 3 dialogs to enable a system extension. Why on earth is it only in the third dialog that a 3rd party developer can only explain why all these complex authorization process is required (1 )?

- 2 years after the introduction of SKEL and there is still not a user friendly workflow in macOS to enable Kernel Extensions (or System Extensions). This is quite worrying.

- When the network connection is blocked, the only feedback to the user is the app bouncing in the Dock. This is a bad user experience and one of my fears is that because of the "MAS oriented idea" of embedding the system extension into an app bundle (and all the cumbersome entitlements), this could mean that it will not be possible to use a helper application (such as launchd agent) to provide the UI feedback or to use a launchd daemon that hosts the system extension.

- In addition to the last point, contrary to Apple, 3rd party developers try to support more than the current Operating System version.

- Considering that the date support for the adorable Kernel Extensions are officially is fully stopped is unknown.

- Consdering that if the transition to System Extensions faces the same issues as the transition to KPI in OS X 10.4 (where there were some "funny" issues such as filters not filtering nothing if one NKE did allow a packet and another did not.)

This may lead some 3rd party developers to:

- wait until System Extensions are declared reliable by users and other 3rd parties.

- try to ship applications that support both Kernel Extensions and System Extensions (in order to avoid the user to have to install a new version of the app when updating macOS versions =<10.14 to >=10.15).

So if it was possible to avoid the headache of System Extensions being only embeddable in .app or even needed to be embedded, it would be very welcome.

So to summarize:

- make the OS UX to enable System Extensions user friendly. It's not right now.

- make supporting System Extensions developer friendly in a real software solution. Embedding it in a .app is probably not.

1. assuming the dialog can be customized like when access to Calendar, AddressBoook and so on is requesting

- You can always display your own dialog explaining to the user what is a about to happen and have the user click "continue" to kick off the system dialogs. That was a "demo" in session 714. You can do it your own way.

- It seems easy enough. The goal is to inform the user when software wants to modify their operating system and get their explicit consent. That requires a certain level of hoop-jumping.

- Again, it's a demo. You can add a timeout and additional dialogs. That would probably be a good idea.

- Apple provides updates to previous version of the operatingn system, depending on how big the issue is. I think the problem that Apple is trying to address with these kernel extension changes is the opposite problem. Too often developers don't bother to test or update their kernel extensions for new versions of the operating system. Then, when something breaks, Apple has to work to track down the cause.

There is a third option, alway known as "the great unknown" because it is so rarely explored by 3rd party developers. They could do the following:

1) Pay attention to major changes in the operating system;

2) During the deprecation period, start developing a new version of their software using the new techniques;

3) Write bug reports and request Apple Developer Tech Support for any issues; and

4) Come up with a plan to support customers on legacy platforms while also working with new systems.

They could do this now, and have approximately 15 months to prepare for macOS 10.16. Or, just wait until October 2020 and post a message here saying "Wha happened???".

We moved our macOS NKE-based VPN over to Network Extensions a while back. Although Network Extensions offered us less control over the system traffic it also let us have a single code base for the core functionality on iOS & macOS, as well as offering the possibilty of MDM.

The talk on Network Extensions for Modern macOS offered us some of the control back. The includeAllNetworks and excludeLocalNetworks flags are great to see. But

- Are they only on macOS, or are the Network Extension parts of that talk also applicable to iOS?

- Will those Network Extension flags function if the user is running macOS Mojave?

- iOS 12?

Or are they only going to work on Cataline/iOS13 and later?

Users do tend to upgrade their macOS & iOS versions, but corporate customers upgrade slowly, and they're our market.

One abillity of NKEs that we lost with Network Extensions was the ability to do an 'Always On' VPN which made sure that all traffic from the system was tunneled. Because we could make the NKE load at boot time there was no user dependency. It doesn't sound like this is going to be possible even with the current changes.

The talk referred to Driver Extensions as user-independent, and providing something available at the system level, but not Network Extensions. Is that the case?

Kevin

- Having to display our own dialog is the problem:

. It's the job of the OS vendor to improve and unify the user experience. Not to make it worse.

. <sarcasm>Considering the solutions that are/could be based on System Extensions and which are bundled with the OS do not require these steps. why not show them to the users if they are so valuable to the user experience?</sarcasm>

- Honestly, I don't know who could consider the UX issues of SKEL, FDA, AppleEvents, etc. not to be a big issue considering every single 3rd party developer I read or know hates/hated these changes b/c the OS does not do its job by proposing a friendly user experience.

- This does not change the fact that embedding the system extensions in an .app does not fit any of the software blueprints for that category of products which has been relying on a main .app to configure the solution, launch daemon(s) and launch agents to provide user feedback,

The third option is always a good one when you have plenty of time.

My $0.14

Thank you for your answer!

And where do we address our "requirements" so we can migrate our kexts so they're supported from user space?

Best!

By the way.., I think I found a but on macOS 10.15 beta 1 regarding kext loading with kextutil command and processing the kextsOSKextSigExceptionHashList entries.

It seems that the utility is trying to validate the signature of entries included on signexception has list 😉

Reported at : FB6139463

Best!

And where do we address our "requirements" so we can migrate our kexts so they're supported from user space?

I’m not sure what you’re asking for here. What sort of KEXT are you shipping?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I’m happy to answer these questions, but I’d prefer if you put them in a new post in Core OS > Networking (because otherwise this thread is going to get out of hand).

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Yes, it should have been a separate question: https://forums.developer.apple.com/message/364670#364670