Microsoft dragging its feet on Linux Secure Boot fix

etech3 · 11-22-2012, 07:14 AM

Linux Foundation's workaround held up by roadblocks

Ztcoracat · 11-22-2012, 10:16 AM

Good article but very un-setteling; IMO-

This is why I haven't installed Fedora on my laptop and I'm dissapointed that I can't-

The whole UEFI thing is hard to understand and hard to understand (for me) how to get around it but this is just how I perceive it-

TobiSGD · 11-22-2012, 10:21 AM

I can only repeat that again: Please educate yourself about UEFI and Secure Boot. UEFI is not the same as Secure Boot, there is nothing wrong with UEFI at all.

Ztcoracat · 11-22-2012, 10:29 AM

Thanks TobiSGD!
I downloaded the PDF from the Linux Foundation and started reading it.
http://www.linuxfoundation.org/publi...open-platforms

baldy3105 · 11-23-2012, 06:03 PM

There's a surprise, Microsoft using extortion tactics to block competition. Who'd have thought it?

John VV · 11-23-2012, 06:56 PM

it might be unintentional ,but i do not think that any one did not "see this coming"

http://blog.hansenpartnership.com/ad...-uefi-signing/
http://linux.slashdot.org/story/12/1...loader-delayed

now the big question is
in the coming months/years will this be repeated ?
( looking into my "Christal ball" i see a blurry and foggy "yes" )

H_TeXMeX_H · 11-24-2012, 04:40 AM

Quote:

Originally Posted by TobiSGD

I can only repeat that again: Please educate yourself about UEFI and Secure Boot. UEFI is not the same as Secure Boot, there is nothing wrong with UEFI at all.

Are you sure about that ?
http://linux.slashdot.org/story/12/1...ndows-and-rhel

As for Secure boot I have posted comments here:
http://www.linuxquestions.org/questi...ix-4175438264/

syg00 · 11-24-2012, 04:54 AM

I know this is a serious issue for the Linux community, but in this part of the world, the retailers have been spooked into selling off current Win7 machines *real* cheap.
M$oft is pushing Win8 real hard. So I'm looking to get some current laptops cheap and multi-boot to my hearts content for the next few years at least.

Fuck the lot of them.

TobiSGD · 11-24-2012, 11:41 AM

Quote:

Originally Posted by H_TeXMeX_H

Are you sure about that ?
http://linux.slashdot.org/story/12/1...ndows-and-rhel

So there is a bug in one implementation of UEFI from Lenovo. This says exactly what about UEFI in general?
To me it says that there is something wrong with that exact Lenovo machine, not that there is something wrong with UEFI.

sundialsvcs · 11-24-2012, 09:59 PM

I personally am not inclined toward conspiracy theories.

Remember that all of these technologies are very much release 1.0 and I do suspect that they will turn out to be mostly snake-oil in practice. We shall see, but I detect the design-work of a crypto neophyte in the whole UEFI and Secure (sic...) Boot concepts.

H_TeXMeX_H · 12-01-2012, 07:32 AM

There is now the ability to use Secure Boot WITHOUT any dealing with the devil ... I mean M$:
http://mjg59.dreamwidth.org/20303.html

Quote:

I'm pleased to say that a usable version of shim is now available for download. As I discussed here, this is intended for distributions that want to support secure boot but don't want to deal with Microsoft. To use it, rename shim.efi to bootx64.efi and put it in /EFI/BOOT on your UEFI install media. Drop MokManager.efi in there as well. Finally, make sure your bootloader binary is called grubx64.efi and put it in the same directory.

Now generate a certificate and put the public half as a binary DER file somewhere on your install media. On boot, the end-user will be prompted with a 10-second countdown and a menu. Choose "Enroll key from disk" and then browse the filesystem to select the key and follow the enrolment prompts. Any bootloader signed with that key will then be trusted by shim, so you probably want to make sure that your grubx64.efi image is signed with it.

If you want, you're then free to impose any level of additional signing restrictions - it's entirely possible to use this signing as the basis of a complete chain of trust, including kernel lockdowns and signed module loading. However, since the end-user has explicitly indicated that they trust your code, you're under no obligation to do so. You should make it clear to your users what level of trust they'll be able to place in their system after installing your key, if only to allow them to make an informed decision about whether they want to or not.

This binary does not contain any built-in distribution certificates. It does contain a certificate that was generated at build time and used to sign MokManager - you'll need to accept my assurance that the private key was deleted immediately after the build was completed. Other than that, it will only trust any keys that are either present in the system db or installed by the end user.

A couple of final notes: As of 17:00 EST today, I am officially (rather than merely effectively) no longer employed by Red Hat, and this binary is being provided by me rather than them, so don't ask them questions about it. Special thanks to everyone at Suse who came up with the MOK concept and did most of the implementation work - without them, this would have been impossible. Thanks also to Peter Jones for his work on debugging and writing a signing tool, and everyone else at Red Hat who contributed valuable review feedback.