Library validation and CoreMedia I/O plug-ins

Code Signing General Gatekeeper Developer ID

ieo OP

Created Apr ’20

Replies 19

Boosts 0

Views 8.3k

Participants 12

Hi!

The problem I want to discuss is not new, but it is becoming more and more critical for the project I'm working on. So I have to rise it again.

Our project is a virtual webcam for macOS implemented as a CoreMedia I/O DAL plug-in. Plug-in is installed at /Library/CoreMediaIO/Plug-Ins/DAL and can be loaded into any client application that wants to use the webcam.

The problem appeared when Apple introduced 'Hardened Runtime' in macOS Mojave which by default turns on 'Library Validation' feature. Library validation disables loading for frameworks/plugins/libraries which are either: 1) not signed; 2) signed but 'Team Identifier' in signing certificate is different than certificate of a client application signature. As a result, even though our plugin is properly signed and notarized, it can't be loaded into client application with hardened runtime because of that 2nd case.

First alarming incident was last year when Google Chrome on macOS enabled hardened runtime, and stopped showing our webcam in the list. I requested a technical support (case ID for TSI: 718328224), then made a feedback to Apple (FB7071665) about any possible solutions for our case, at least in the future versions of macOS. But I see there's still no reaction there.

Now things are getting worse. Skype and Zoom stopped support our webcam for the same reason. Some others announced they will do this too. There's a possibility to add 'com.apple.security.cs.disable-library-validation' entitlement to the client application - that would help with our issue. But Zoom and Skype refuse to add this because of security reasons - after some security exploits were uncovered.

The situation is quite critical for our product as many users use our webcam only for Zoom, Skype and similar applications.

So, the question is: are there any possible workarounds for our case? I know that for audio plugins (VST, etc.) there's a special entitlement: 'com.apple.security.temporary-exception.audio-unit-host' that allows loading even unsigned plugins into hosting application. Why there's no such entitlement for DAL plugins? Or will it appear in macOS 10.16? I think it would be reasonable to add an entitlement that would only reject loading of unsigned plugins, but would allow loading of plugins with different 'Team ID' in signing certificate.

Boost

helicon21 OP

Nov ’21

Asked my employer today to swap out my MBP for a Windows laptop to "work around" this issue. An application we use daily lacks features to flip a camera's image (mounted inverted), correct for white balance, or chromakey. Trivial fix with virtual camera software from many developers including Logitech's own "Mac-compatible" software that comes with the camera.

As long as I'm making a departing shot without any hope of a real fix, I'll just say this is classic Apple telling people how they should be using their hardware and software, and even Apple-fans with a dozen devices have their limits. A simple "Allow/Deny" on providing the hardened runtime an application is requesting would unblock users, but instead we get "don't hold it that way". Not directed at you @eskimo but I hope you'll pass along this sentiment.

j.weinert OP

Dec ’21

And once again, in true Apple fashion the issue gets recognised and simply ignored.

I really don't understand why this company strives to make macOS less and less useful, removes more and more unique features and APIs that made the system so great in the past.

Sad.

DrXibber OP

Dec ’21

I just wanted to note that the CoreAudio team has done a superb job of dealing with these same basic problems. I develop both coreaudiod drivers and CoreMediaIO DAL drivers and note the following:

Under Apple Silicon (Big Sur, Monterrey) CoreAudio loads code signed Intel binary audio output drivers just fine, it appears to run them in a special Intel service helper that runs under Rosetta2. Even in an app that has not adopted the Hardened runtime AVFoundation only vends CMIO DAL drivers if they have the appropriate fat binary code. The CoreAudio support is seamless and invisible to the user and ideally we'd have the same situation for CMIO sometime in the near future.

So QuickTime Player is unable to access even Apple Silicon signed CMIO DAL drivers even while exposing Intel versions of analogous audio drivers. Currently AVFoundation is loading CMIO DAL drivers into the process using the driver. I believe this code should be run in a service process. QTKit used this technique and it was very fast so it's not a performance issue AFAIK.

I believe that Apple, by virtue of the fact that Apple code signed libraries are approved by the Hardened runtime, could create a CMIO DAL driver that would seamlessly "remote" all the 3rd party (code signed) CMIO DAL drivers into an XPC process. I believe this technique was used to allow QTKit to vend 32-bit VDIG drivers to 64-bit applications.

I think it's a lot to expect that end users understand these types of issues: if they install an app that includes a virtual camera driver (or in the case of Blackmagic, a hardware device), I think it's clear their intent is to make use of those features.

Khaos_Tian OP

Feb ’22

macOS 12.3 introduces the new Camera Extension (CMIOExtension), which allows the third party apps to provide virtual media I/O device without running into the limitation like the existing DAL Plug-Ins.

The document on this API is lacking right now, but Xcode 13.3 included the extension template with a working reference implementation.