4 ms·

Library validation has nothing to do with drivers. Depends on the type of driver. For GPU drivers, it is indeed a problem. I'm going to assume from your comme

Library validation has nothing to do with drivers. Depends on the type of driver. For GPU drivers, it is indeed a problem. I'm going to assume from your comment that you haven't actually written many (any?) device drivers on macOS, so let me explain roughly how GPU drivers on macOS work: - One or more kexts provide an IOFramebuffer implementation, plus an IOAccelerator object which listens for various types of user clients. The IOFB and IOAccel are typically clients of the GPU's IOPCIDevice object and handle its interrupts and memory. - A variety of user space plugins (essentially dynamic libraries) are loaded into any process wishing to use GPU acceleration, with different plugins for Metal, OpenGL, and so on. The kext communicates directly with the hardware and manages memory, but the user space plugin tends to deal with the higher level tasks such as generating command streams, compiling shaders, etc., and they talk to the kernel driver using the IOKit user client mechanism. The plugins also provide the back-end implementations for the app-facing APIs such as OpenGL, Metal, and OpenCL. In recent macOS versions, WindowServer, the process responsible for drawing your macOS desktop, has had the library-validation codesigning flag enabled. This flag enforces that any code loaded into the process must be signed using a certificate from the same Developer Team ID as the main executable or Apple's own certificate. This means, no third-party plugins can be loaded. This also means third-party GPU drivers can't work with most Apple apps and WindowServer itself, because they require aforementioned user space plugin. For similar reasons, classic Core Audio plugins (not to be confused with Core Audio Server Plugins) are deprecated - they used to be loaded directly into the process using Core Audio, which no longer works on apps with library-validation enabled. Drivers which are implemented entirely as kexts or which are loaded into a "server" user space process are not affected by this, which I guess is what you were talking about.

saagarjha 7y ago
> I'm going to assume from your comment that you haven't actually written many (any?) device drivers on macOS, so let me explain roughly how GPU drivers on macOS work I have written a couple toy ones, but nothing major and I'll admit I have no specialized knowledge of graphics drivers. > Drivers which are implemented entirely as kexts or which are loaded into a "server" user space process are not affected by this, which I guess is what you were talking about. Yes, I was talking about how anything loaded into the kernel does not have to deal with library validation (though there is still the check that it's signed with a valid KEXT certificate, which I assume Nvidia already has). I generally call the user-space portion of a driver that's loaded into applications to be plugins and keep them outside of the umbrella of "drivers" (which I reserve for the KEXT portion only) but in this case I think we both understand what's going on and are just disagreeing on what the terminology is. > For similar reasons, classic Core Audio plugins (not to be confused with Core Audio Server Plugins) are deprecated - they used to be loaded directly into the process using Core Audio, which no longer works on apps with library-validation enabled. These are plugins that implement AudioHardwarePlugIn, right? I think that they're being disabled by default anyways to get people to migrate to AudioServerPlugin, but they were deprecated way before library validation was even a thing because they inherited the sandbox of the application they were loaded into, which was already causing them to fail in odd ways.
- pmjordan 7y ago
  I generally call the user-space portion of a driver that's loaded into applications to be plugins and keep them outside of the umbrella of "drivers" but in this case I think we both understand what's going on and are just disagreeing on what the terminology is. Given that the kext is essentially useless without the userspace component (and vice versa), I don't think it's unreasonable to call the plugin part of the driver. Note also that it's installed in /Library/Extensions. This certainly also matches the user experience: they download the NVIDIA "driver" installer which happens to install a bunch of kexts and also the user space components at the same time. These are plugins that implement AudioHardwarePlugIn, right? Correct. More generally, the IOCFPlugin mechanism, which paired user space components with kexts, is essentially dead for third-party driver developers thanks to the increasing lock-down of user space processes.

saagarjha 7y ago

> I'm going to assume from your comment that you haven't actually written many (any?) device drivers on macOS, so let me explain roughly how GPU drivers on macOS work I have written a couple toy ones, but nothing major and I'll admit I have no specialized knowledge of graphics drivers. > Drivers which are implemented entirely as kexts or which are loaded into a "server" user space process are not affected by this, which I guess is what you were talking about. Yes, I was talking about how anything loaded into the kernel does not have to deal with library validation (though there is still the check that it's signed with a valid KEXT certificate, which I assume Nvidia already has). I generally call the user-space portion of a driver that's loaded into applications to be plugins and keep them outside of the umbrella of "drivers" (which I reserve for the KEXT portion only) but in this case I think we both understand what's going on and are just disagreeing on what the terminology is. > For similar reasons, classic Core Audio plugins (not to be confused with Core Audio Server Plugins) are deprecated - they used to be loaded directly into the process using Core Audio, which no longer works on apps with library-validation enabled. These are plugins that implement AudioHardwarePlugIn, right? I think that they're being disabled by default anyways to get people to migrate to AudioServerPlugin, but they were deprecated way before library validation was even a thing because they inherited the sandbox of the application they were loaded into, which was already causing them to fail in odd ways.

pmjordan 7y ago
I generally call the user-space portion of a driver that's loaded into applications to be plugins and keep them outside of the umbrella of "drivers" but in this case I think we both understand what's going on and are just disagreeing on what the terminology is. Given that the kext is essentially useless without the userspace component (and vice versa), I don't think it's unreasonable to call the plugin part of the driver. Note also that it's installed in /Library/Extensions. This certainly also matches the user experience: they download the NVIDIA "driver" installer which happens to install a bunch of kexts and also the user space components at the same time. These are plugins that implement AudioHardwarePlugIn, right? Correct. More generally, the IOCFPlugin mechanism, which paired user space components with kexts, is essentially dead for third-party driver developers thanks to the increasing lock-down of user space processes.