future plans for Deprecation of KEXT

Question

We are an IRM company and we provide data security by controlling usage of documents like viewing, printing, editing within applications like MS Office etc. We also encrypt documents and must decrypt the document before the applications like MS Office etc reads the document. Our code must be present inside the application/process in order to achieve this.

As now apple is becoming strict by introducing Runtime hardening & deprecating KEXT. Is apple planning to provide relevant API's to cater need of such kind of businesses? And if not, will apple continue support for KEXT till then? What are future planning and timelines for it?

Kernel

869

Posted by

sahil000005

Reply

Add a Comment

Answer 1

Our code must be present inside the application/process in order to achieve this.

This puts you on very shaky ground. Implementing a KEXT is a tricky long-term compatibility proposition; implementing a KEXT that loads code into arbitrary apps is even more so.

Is apple planning to provide relevant API's to cater need of such kind of businesses?

I can’t comment on The Future™ beyond what’s been officially announced. You can find that official story in Deprecated Kernel Extensions and System Extension Alternatives.

Of course this article assumes that you’re only shipping a KEXT. If you use that KEXT to loads code into arbitrary apps you may encounter other security hardening that only applies to user space code (like the hardened runtime).

My general advice in situations like this is that you file an enhancement request that describes your overall requirements, how you’re currently meeting those requirements with a KEXT, and a rough sketch of what facilities you would like the system to provide.

Please post your bug number, just for the record.

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

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

Posted by

eskimo

Add a Comment

Answer 2

Apple tends to not discuss future plans in public.

In the mean time, feel free to file enhancement requests for things you'd like going forward via the bug reporter, linked below, adding your report #(s) to your thread for reference, thanks and good luck.

Posted by

KMT

Add a Comment

Answer 3

Our code must be present inside the application/process in order to achieve this.

This puts you on very shaky ground. Implementing a KEXT is a tricky long-term compatibility proposition; implementing a KEXT that loads code into arbitrary apps is even more so.

Is apple planning to provide relevant API's to cater need of such kind of businesses?

I can’t comment on The Future™ beyond what’s been officially announced. You can find that official story in Deprecated Kernel Extensions and System Extension Alternatives.

Of course this article assumes that you’re only shipping a KEXT. If you use that KEXT to loads code into arbitrary apps you may encounter other security hardening that only applies to user space code (like the hardened runtime).

My general advice in situations like this is that you file an enhancement request that describes your overall requirements, how you’re currently meeting those requirements with a KEXT, and a rough sketch of what facilities you would like the system to provide.

Please post your bug number, just for the record.

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

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

Posted by

eskimo

Add a Comment

future plans for Deprecation of KEXT

Accepted Reply

Replies