[personal profile] mjg59
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.
Page 1 of 5 << [1] [2] [3] [4] [5] >>

Non-secure boot fallback.

Date: 2012-12-01 02:06 am (UTC)
From: [identity profile] jordanu [launchpad.net]
What will the shim do if booted on a UEFI system with secure boot disabled?

Ideally I'd like to configure things so that if someone boots my media (Super GRUB2 Disk) without secure boot there is no user intervention required to get to SG2D, so I would like it to just load the grubx64.efi automatically in that case.

Date: 2012-12-01 05:09 am (UTC)
From: (Anonymous)
Does this only work for Linux or will this work for FreeBSD as well?
From: (Anonymous)
After the trouble the Linux Foundation has it would be interested it see the successful method. Particularly if it can be made done without using windows.

I don't mean to be mean but if someone does not trust you. Providing the process and list of costs say here you can do this yourself if you don't trust me.
.

thank you

Date: 2012-12-01 01:41 pm (UTC)
From: (Anonymous)
Matt, thank you and everyone involved for having gone through the trouble for us too. Shame on Microsoft for "innovating" in making that trouble.

--
Michael Shigorin

Microsoft signed? Is that "secure"?

Date: 2012-12-01 02:16 pm (UTC)
From: (Anonymous)
If Microsoft signs it couldn't they als sign malware to be authentic? How is that secure? Ok, Microsoft wouldn't do something like doing bat things to comeptitor like linux but keys can get lost or a "admin" at Microsoft goes beserk.

UEFI

Date: 2012-12-01 02:18 pm (UTC)
From: (Anonymous)
Will this be in the SuSe distros?

Re: Non-secure boot fallback.

Date: 2012-12-01 02:34 pm (UTC)
From: (Anonymous)
Is your departure from RedHat in any way related
to your work on the shim?

thank you

Date: 2012-12-01 02:52 pm (UTC)
From: (Anonymous)
thank you.

Re: Microsoft signed? Is that "secure"?

Date: 2012-12-01 02:54 pm (UTC)
From: [identity profile] http://apebox.org/wordpress/
They could accidentally sign malware as authentic, but there is support for blacklisting specific signed binaries to ban them from booting, and provision in the Secure Boot spec for distributing the blacklist updates via Windows Update (and other OSes may implement it too)

Re: Microsoft signed? Is that "secure"?

Date: 2012-12-01 03:00 pm (UTC)
From: (Anonymous)
UEFI provides a guarantee that some random program can't be loaded before the operating system gets started.

Naer a week passes when we don't hear of new malware breaching Windows defences; which seems to have escaped the attention of those who would spruik this (secure boot) dreadful imposition.

The greatest threat appears to lie in Windows itself, either application or system code. Guarantees that windows loads without interference seems to me to be a hollow victory.

Newall
From: (Anonymous)
You see, MS has been recently caught on signing serious industrial spyware/sabotage tool with their valid signature. So I have no doubt they will also sign any kind of bootkit/rootkit, should some big guys need it to do evil things on Iran PCs at their factories... or spy at *your* PC. Or someone else PC. Or whatever. If they signed hardcore industrial espionage kit, you can exepct absolutely ANYTHING from such vendor. So you can't expect security at all.

P.S. still this bootloader is an incredible workaround to these crappy initiatives where you're FORCED to "trust" to entities you have no reason to trust at all. However as for me at this point I would consider whole x86 platform with UEFI to be untrusted due to all this activity. If someone forces you to "trust" by pointing you with their gun and leaving no other options, you know, this "trust" is a big fake.

P.s.: "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." - B. Franklin.

Will MS revoke it?

Date: 2012-12-01 03:43 pm (UTC)
From: (Anonymous)
More importantly, can they?

ARM systems support?

Date: 2012-12-01 04:09 pm (UTC)
From: (Anonymous)
This appears to be an x86 solution/work-around. What about ARM systems? Are you working on a version for that?
From: (Anonymous)
Amen to that (and kudos to BF)!

P.S. To MG - I like your (not)captcha technique. Yours, or did you get it elsewhere? :-)

-Rubberman

Good luck

Date: 2012-12-01 04:14 pm (UTC)
From: (Anonymous)
I'm sure I speak for more than just me in wishing you all the best in your new endeavors! Keep on bloggin'!

-Rubberman
From: (Anonymous)
The uploader is in Silverlight? Seriously?

Microsoft is just trolling at this point.

Re: Will MS revoke it?

Date: 2012-12-01 04:30 pm (UTC)
From: (Anonymous)
And so we are back to being forced to "Trust" Microsoft, at least if that system ever boots MS-Windows and updates and gets a new blacklist that does blacklist your key.

I still find this whole situation intolerable.

Re: ARM systems support?

Date: 2012-12-01 07:03 pm (UTC)
From: (Anonymous)
> What about ARM systems?
ARMs all have very different ideas on how this thing implemented. Many ARMs do not implement this "feature" at all. Some do implement it but can leave it inactive, depending on eFuse state in CPU itself. Some are restricted/locked though. Most notably some smart phones, etc. Especially those locked to particular operator and so on. In fact secure-boot-like techniques were here for an ages in ARMs and appeared much earlier to protect operator locks and other restrictions. Ages ago before UEFI made it to PC. Though this curtain rather uplifts these days when Linux-based things got popular and users started to demand root rights and unlocked bootloaders by writting petitions and so on.

This far you can expect most restricted devices to come from apple (I doubt they will allow you to boot your own code without hacks, ever) and MS (who wants to be like an apple). For other devices your mileage may vary. Yes, we have to be a little picky in choosing devices. iDevices from apple are clearly not our friend - they targetnig careless iDiots who could be easily fooled into locked-down trap. Whole device design serves to taking away user's freedom. So device does not serves user. It serves apple and their needs. As simple as that. In fact such devices are just trojan horses on their own. Yet not each and every human being can recognize that.
Page 1 of 5 << [1] [2] [3] [4] [5] >>

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Member of the Linux Foundation Technical Advisory Board. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags