Authored by: Gringo_ on Tuesday, February 26 2013 @ 10:53 PM EST |
[ Reply to This | Parent | # ]
|
|
Authored by: jesse on Wednesday, February 27 2013 @ 07:23 AM EST |
The key is only to validate signatures.
The bigger problem is when MS doesn't use the same signing certificate... Which
is what they do on Surface RT.
You can't boot on one of those because the certificate used isn't in the chain
used for signing the linux shim... thus the shim fails.[ Reply to This | Parent | # ]
|
|
Authored by: Magpie on Thursday, February 28 2013 @ 05:22 PM EST |
You need to track the WHOLE thread on the kernel mailing list. The issues
didn't come out at first, but I think later in the thread Linus actually made by
far the most important point.
What the thread was about was people with modules that are to be loading into
the kernel was how those keys were to be trusted - and the Red Hat solution was
to encapsulate the module key in the Microsoft signed certificate - so was
subject to the revocation of the certificate by Microsoft (I struggled to
understand the whole issue but this was what it semeed to come down to). This
was because these modules may allow a rebooting to Windows 8. There was also
worry that there was a contract in place that allows Microsoft to revoke the
certificate if the kernel didn't prevent bad code getting loaded.
What I think Linus was saying was forget the Microsoft Certificate - signing
modules is a good idea but it must be user controlled. It should be users who
decided whether or not a module should be loaded and whether or not a
certificate should be revoked or not. What he didn't say explicitly but I think
was implied by his words was that the developers (Red Hat in this case) should
provide a similar signing mechanism, but one in control of the user rather than
Microsoft.[ Reply to This | Parent | # ]
|
|