<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jun 3, 2015, at 4:46, René J.V. Bertin <<a href="mailto:rjvbertin@gmail.com">rjvbertin@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Wednesday June 03 2015 16:47:39 Joshua Root wrote:<br><br><blockquote type="cite">Finally got around to trying an unsigned kext, and the answer is no,<br>neither kextload nor kextutil will load unsigned kexts at all (without<br>kext-dev-mode=1 in the kernel boot args).<br></blockquote><br>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.<br></blockquote></div><br><div>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:</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://xref.plausible.coop/source/xref/macosx-10.10.1/kext_tools-384.1.4/security.c#1238">http://xref.plausible.coop/source/xref/macosx-10.10.1/kext_tools-384.1.4/security.c#1238</a></div><div><br></div><div>It’s easy to runtime patch kextd to accept kexts signed with additional anchors, but that’s probably not shippable as a general solution.</div><div><br></div><div>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.</div><div><br></div><div>Personally, I’m just staying with Mavericks.</div><div><br></div><div>-landonf</div></body></html>