![[personal profile]](http://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59I'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.
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.
![[identity profile]](http://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Non-secure boot fallback.
Date: 2012-12-01 02:06 am (UTC)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.
Re: Non-secure boot fallback.
From:Re: Non-secure boot fallback.
From: (Anonymous) - Date: 2012-12-01 02:34 pm (UTC) - ExpandRe: Non-secure boot fallback.
From:Re: Non-secure boot fallback.
From: (Anonymous) - Date: 2012-12-02 01:09 am (UTC) - Expandno subject
Date: 2012-12-01 05:09 am (UTC)(no subject)
From:(no subject)
From:(no subject)
From: (Anonymous) - Date: 2012-12-02 06:29 pm (UTC) - ExpandCan this be used to bring up SYSLINUX
From: (Anonymous) - Date: 2012-12-02 05:38 am (UTC) - ExpandRe: Can this be used to bring up SYSLINUX
From:Would you mind doing a post on what you did to get a signed shim.
Date: 2012-12-01 07:17 am (UTC)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.
.
Re: Would you mind doing a post on what you did to get a signed shim.
From:Re: Would you mind doing a post on what you did to get a signed shim.
From: (Anonymous) - Date: 2012-12-01 04:28 pm (UTC) - ExpandRe: Would you mind doing a post on what you did to get a signed shim.
From: (Anonymous) - Date: 2012-12-02 07:02 am (UTC) - ExpandRe: Would you mind doing a post on what you did to get a signed shim.
From:Re: Would you mind doing a post on what you did to get a signed shim.
From: (Anonymous) - Date: 2013-02-16 06:47 am (UTC) - ExpandRe: Would you mind doing a post on what you did to get a signed shim.
From: (Anonymous) - Date: 2012-12-05 01:31 am (UTC) - Expandthank you
Date: 2012-12-01 01:41 pm (UTC)--
Michael Shigorin
Microsoft signed? Is that "secure"?
Date: 2012-12-01 02:16 pm (UTC)Re: Microsoft signed? Is that "secure"?
From:This "security" is fake. It's "restricted" boot, not "secure".
From: (Anonymous) - Date: 2012-12-01 03:32 pm (UTC) - ExpandRe: This "security" is fake. It's "restricted" boot, not "secure".
From: (Anonymous) - Date: 2012-12-01 04:12 pm (UTC) - ExpandRe: Microsoft signed? Is that "secure"?
From: (Anonymous) - Date: 2012-12-01 08:06 pm (UTC) - ExpandRe: Microsoft signed? Is that "secure"?
From:Re: Microsoft signed? Is that "secure"?
From:Re: Microsoft signed? Is that "secure"?
From: (Anonymous) - Date: 2012-12-02 03:22 am (UTC) - ExpandRe: Microsoft signed? Is that "secure"?
From: (Anonymous) - Date: 2012-12-01 03:00 pm (UTC) - ExpandRe: Microsoft signed? Is that "secure"?
From: (Anonymous) - Date: 2012-12-01 09:02 pm (UTC) - ExpandRe: Microsoft signed? Is that "secure"?
From:UEFI
Date: 2012-12-01 02:18 pm (UTC)Re: UEFI
From: (Anonymous) - Date: 2012-12-01 10:40 pm (UTC) - ExpandRe: UEFI
From: (Anonymous) - Date: 2012-12-02 02:50 am (UTC) - Expandthank you
Date: 2012-12-01 02:52 pm (UTC)Will MS revoke it?
Date: 2012-12-01 03:43 pm (UTC)Re: Will MS revoke it?
From:Re: Will MS revoke it?
From: (Anonymous) - Date: 2012-12-01 04:30 pm (UTC) - ExpandRe: Will MS revoke it?
From: (Anonymous) - Date: 2012-12-03 04:56 pm (UTC) - ExpandRe: Will MS revoke it?
From: (Anonymous) - Date: 2012-12-04 02:49 am (UTC) - ExpandARM systems support?
Date: 2012-12-01 04:09 pm (UTC)Re: ARM systems support?
From:Re: ARM systems support?
From: (Anonymous) - Date: 2012-12-01 07:03 pm (UTC) - ExpandGood luck
Date: 2012-12-01 04:14 pm (UTC)-Rubberman
archival time
Date: 2012-12-01 09:42 pm (UTC)Re: archival time
From:So Linux devs/users pay MS ...
Date: 2012-12-01 11:25 pm (UTC)Work-arounds are all well and good, and many large kudos for this one, but something is seriously wrong with this picture and needs a rather large complaint filed with the FTC.
Re: So Linux devs/users pay MS ...
From:Re: So Linux devs/users pay MS ...
From: (Anonymous) - Date: 2012-12-02 02:53 am (UTC) - ExpandRe: So Linux devs/users pay MS ...
From: (Anonymous) - Date: 2012-12-03 04:57 pm (UTC) - ExpandRe: So Linux devs/users pay MS ...
From: (Anonymous) - Date: 2012-12-02 10:15 pm (UTC) - ExpandHow about doing this in reverse?
Date: 2012-12-02 04:03 am (UTC)A defense contractor sells the DoD what amounts to a commodity Intel or AMD x64 computer that's locked down to only boot a specific, DoD-approved software stack - a stack that is NOT based on MS-Windows.
The DoD buys the computers but the project is eventually scrapped before full deployment.
To make these computers more attractive at auction, the DoD gets the defense contractor or the motherboard manufacturer to sign a version of Matthew's bootloader or something similar.
This bootloader can now be used to boot ... wait for it ... Windows. Or any other OS.
The DoD now gets "used computer" prices at auction instead of "scrap metal" prices.
Secure Boot bootloader for distributions available now
Date: 2012-12-02 12:46 pm (UTC)Wake up!
Date: 2012-12-02 06:24 pm (UTC)The current situation is no different than allowing for instance Ford to have some sort of signing key that allows all car engines manufactured worldwide the ability to start. Believing that any single company should have this kind of power over its competitors is insane no matter whether the controlling company is Microsoft, RedHat, Oracle or whoever.
As was predicted before this whole mess started to come into effect there are already problems for users of alternative operating systems. Its only going to get worse from here on.
While its nice that you have come up with a work around, a work around is all it is and it can be made unusable at any point and my guess is that is exactly what will happen with your method and any other future method. Microsoft will interfere with anything that works. Bet on it.
No, the real solution is to remove Microsoft's ability to control this process and hand it over to an international unbiased standards body. If they do not do it willingly then legal action is required. NOTHING ELSE WILL WORK PERMANENTLY. No other solution will serve to address the freedom of consumers to use computers and operating systems as the consumer wishes.
WAKE UP!
Re: Wake up!
From: (Anonymous) - Date: 2012-12-30 02:56 pm (UTC) - Expand+1 @ Wake Up!
Date: 2012-12-02 06:49 pm (UTC)Re: +1 @ Wake Up!
From: (Anonymous) - Date: 2012-12-02 07:04 pm (UTC) - ExpandRe: +1 @ Wake Up!
From: (Anonymous) - Date: 2012-12-03 12:04 am (UTC) - ExpandRe: +1 @ Wake Up!
From: (Anonymous) - Date: 2012-12-03 12:36 am (UTC) - ExpandRe: +1 @ Wake Up!
From: (Anonymous) - Date: 2012-12-30 02:39 pm (UTC) - ExpandPointers on signing
Date: 2012-12-03 06:50 am (UTC)Re: Pointers on signing
From:Thanks
Date: 2012-12-03 07:42 am (UTC)How about a 32 bit system ?
Date: 2012-12-03 12:15 pm (UTC)Do you have a 32 bit UEFI binary ? I have a 32 bit UEFI system that is/will have secure boot on it and - thus would really like to ensure it works with shim before release.
Re: How about a 32 bit system ?
From:Re: How about a 32 bit system ?
From:Re: How about a 32 bit system ?
From:Re: How about a 32 bit system ?
From:Network (PXE) boot
Date: 2012-12-03 06:51 pm (UTC)What about if I want to run from Read-only media, and do an unattended reboot?
Re: Network (PXE) boot
From:Where do I find mokManager.efi
Date: 2012-12-03 08:27 pm (UTC)Re: Where do I find mokManager.efi
From:And how about grub-install generated .efi files?
Date: 2012-12-03 09:51 pm (UTC)But what about grub-install (grub-mkimage...) grubx64.efi files?
These files seem to contain information about where is the "root" (grub root) partition, in particular the variables "root" and "prefix" change from system to system.
So, if this file changes from system to system and is generated during the install process, how is one supposed to have it signed without disclosing the private key?
Re: And how about grub-install generated .efi files?
From:Which licenze do you use for shim?
From: (Anonymous) - Date: 2012-12-03 11:29 pm (UTC) - ExpandSignatures for the source/binary
Date: 2012-12-04 06:34 am (UTC)Re: Signatures for the source/binary
From:Re: Signatures for the source/binary
From: (Anonymous) - Date: 2012-12-04 07:28 am (UTC) - ExpandSurface
Date: 2012-12-04 06:40 pm (UTC)Re: Surface
From:Re: Surface
From:Re: Surface
From:Re: Surface
From:Re: Surface
From:Re: Surface
From: (Anonymous) - Date: 2012-12-04 08:21 pm (UTC) - ExpandFabio
Date: 2012-12-04 07:52 pm (UTC)could you version shim-signed.tgz on the http server?
Thanks.