On Jun 3, 2015, at 4:46, René J.V. Bertin <[email protected]> wrote:
> On Wednesday June 03 2015 16:47:39 Joshua Root wrote:
>
>> Finally got around to trying an unsigned kext, and the answer is no,
>> neither kextload nor kextutil will load unsigned kexts at all (without
>> kext-dev-mode=1 in the kernel boot args).
>
> Regardless of where you're loading them from? IIRC there was a distinction
> between kexts installed under /System and kexts installed in "user land",
> probably in places where they're not picked up by the default kext search
> algorithm.
Mavericks allows unsigned kexts in /Library, but Yosemite requires that all
kexts be signed by Apple, or by a ‘blessed’ Apple-signed Developer ID
certificate, regardless of location:
http://xref.plausible.coop/source/xref/macosx-10.10.1/kext_tools-384.1.4/security.c#1238
It’s easy to runtime patch kextd to accept kexts signed with additional
anchors, but that’s probably not shippable as a general solution.
It may also be possible to bypass kextd by just calling OSKextLoadWithOptions()
directly, but if that does work in Yosemite, it seems very likely to break in
Yosemite+1 of OS X when they start applying additional iOS-style restrictions
based on code signing entitlements + MAC.
Personally, I’m just staying with Mavericks.
-landonf_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
