unsigned kexts on Yosemite
Landon J Fuller
landonf at macports.org
Fri Oct 24 18:12:41 PDT 2014
On Oct 24, 2014, at 5:03 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Oct 23, 2014, at 11:24 AM, Landon J Fuller wrote:
>>
>> On Oct 22, 2014, at 5:25 PM, Ryan Schmidt wrote:
>>
>>> On Oct 22, 2014, at 1:40 PM, Dan Ports wrote:
>>>
>>>> I haven't upgraded to Yosemite myself yet, but I'm hearing that in
>>>> 10.10 the system refuses to load any unsigned kernel modules by
>>>> default.
>>>
>>> I can understand the security motivations behind this change. You don't want untrusted code running in your kernel.
>>
>> It’s no more untrusted than any other code being run from MacPorts :-)
>
> There's most certainly a difference in the potential for damage from bad kernel code vs. bad user code. One can cause a kernel panic; the other can’t.
If you figure out how signing fixes panic-causing driver bugs, please let me know, because it doesn’t seem to be working for my own — properly-signed — kext code :-)
As far as I can see, it doesn’t even prevent hardware vendors from bricking compatible 3rd-party chipsets:
http://arstechnica.com/information-technology/2014/10/windows-update-drivers-bricking-usb-serial-chips-beloved-of-hardware-hackers/
That driver was signed by Microsoft and delivered via Windows Update. FTDI has since apologized:
http://www.ftdichipblog.com/?p=1053
I agree that a kext requires a higher degree of trust, I just don’t think a single-vendor signing regime is a net win for users. Ultimately, the difference between DRM and security rests in who controls the keys. Given that Apple is now positioned to grandfather in existing kexts while blocking the general use of any new ones by simply denying kext signing requests, I’m not particularly enamored with policy changes — such as deleting ports and requiring upstream binary distributions — that make it easier for Apple to fully shut that gate even sooner.
-landonf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20141024/66da1148/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20141024/66da1148/attachment.sig>
More information about the macports-dev
mailing list