On Oct 24, 2014, at 5:03 PM, Ryan Schmidt <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
