![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
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.
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.
Tutorial please? id be infinitely grateful for it.
Date: 2012-12-04 11:19 pm (UTC)first off, i sincerely want to thank you so much for spending $99 and developing such an application in order to thwart microsoft's disabled mental ability/retardedness it has caught up these days.
anyways, you get my gist.
what im trying to do is that im trying to integrate this with hackintosh bootloader from here:
http://sourceforge.net/projects/cloverefiboot/files/Bootable_ISO/
with the ISO 906.
Any help is appreciated. if this can be done, then secure-boot better secure-its-anal-virginity cuz we won't leave any b**ches left behind.
thanks for reading. im definitely looking forward to Microsoft's bitching and lawsuit... crap we better get ready *shurg*
Re: Tutorial please? id be infinitely grateful for it.
Date: 2012-12-04 11:27 pm (UTC)Re: Tutorial please? id be infinitely grateful for it.
Date: 2012-12-04 11:34 pm (UTC)when u say signing key, do you mean a x.509 certificate.. or?
Re: Tutorial please? id be infinitely grateful for it.
From:Re: Tutorial please? id be infinitely grateful for it.
From: (Anonymous) - Date: 2012-12-05 11:33 pm (UTC) - ExpandRe: Tutorial please? id be infinitely grateful for it.
From:no subject
Date: 2012-12-09 07:01 pm (UTC)...Perhaps I just answered my question.
no subject
Date: 2012-12-09 07:19 pm (UTC)no subject
Date: 2012-12-10 12:02 am (UTC)I've signed both the bootloader and vmlinuz with the exact same certificate and the same tool, and enroled the key to the database. What's going on?
no subject
Date: 2012-12-10 12:04 am (UTC)no subject
Date: 2012-12-10 12:06 am (UTC)(no subject)
From: (Anonymous) - Date: 2012-12-10 02:53 am (UTC) - Expand(no subject)
From: (Anonymous) - Date: 2012-12-10 04:20 am (UTC) - Expand(no subject)
From: (Anonymous) - Date: 2012-12-10 04:08 pm (UTC) - Expand(no subject)
From:(no subject)
From: (Anonymous) - Date: 2012-12-10 06:37 pm (UTC) - Expand(no subject)
From: (Anonymous) - Date: 2012-12-10 02:58 am (UTC) - Expand(no subject)
From:no subject
Date: 2012-12-10 12:05 am (UTC)no subject
Date: 2012-12-10 02:59 am (UTC)(no subject)
From: (Anonymous) - Date: 2012-12-10 03:02 am (UTC) - Expand(no subject)
From: (Anonymous) - Date: 2012-12-10 03:10 am (UTC) - Expand(no subject)
From:EFI
Date: 2012-12-31 07:05 pm (UTC)Re: EFI
Date: 2012-12-31 07:13 pm (UTC)The Business Model Drives The Complex
Date: 2013-01-09 01:40 pm (UTC)SONY PS2 is the classic case. SONY PS2 had a very powerful GPU which could be used in clusters to build supercomputers. SONY sold the PS2 at a fraction of what it cost them because they expected to recoup by selling games. They did not anticipate very large numbers of PS2s being purchased to run Linux in clusters. The losses were so bad they tried to renege on letting PS2 run Linux by putting out a software update the turned off the ability. I could see not offering new PS2s with the Linux option but do you really think that you could turn a datacenter cluster into kids buying games by shutting off the Linux option? Did they really think they could undo the lost game sales that way?
Fast-forward and Microsoft is trying to avoid the hole in the "free hardware recouped by paid software" business model by restricting the hardware to just their software in the case of their ARM tablets the where the "secure" boot can't be turned off.
The business model works because people will sell their freedom for $10 discount on a tablet especially when most of them don't understand what they are doing.
how to put it in the /EFI/BOOT?
Date: 2013-02-17 01:12 am (UTC)Trying to create public certificate in Windows 8
Date: 2013-02-19 04:57 pm (UTC)How do i create public certificate (DER file) in Windows 8? Please help!!!
syslinux
Date: 2013-07-12 03:01 am (UTC)IPv6 support by shim bootloader
Date: 2013-07-16 03:21 pm (UTC)My name is Sergey Dremin, serega7@gmail.com(preferred), sergey.dremin@hp.com I'm an HP employee, and I'm working on pxe boot of suse over IPv6. Shim code can not extract the URL of the boot server from the image hangle I put together. I'm trying to recompile the shim code right now to insert some more debug. If you do not mind, can you tell me if you actually tested this on IPv6? If not, then I would point to a problem in the shim code itself, if yes, then it is something in our PXE boot code. I will definately share with you what I find.
Thanks!
Sergey
Re: IPv6 support by shim bootloader
Date: 2013-07-16 03:24 pm (UTC)Surface Pro
Date: 2013-09-11 02:01 am (UTC)change to policy...
Date: 2014-01-30 10:47 pm (UTC)what is GRUB2 being SecureBoot enlightened ? Is that the shim patch for it?
SHIM AND MS
Date: 2014-08-18 08:34 am (UTC)UEFI PXE boot to shim not picking up second stage (grub-x86_64-efi)
Date: 2014-11-03 06:28 pm (UTC)What is the best way to debug the shim?
Date: 2015-08-18 11:55 pm (UTC)So I was able to build the shim on a Solaris system. However, it looks like the shim is not able to load the signed MokManager. After putting in debugging printf, it looks like the authentication process failed. Does this mean there is an issue with my version of pesign? What is the best way to debug the shim's authentication process?
Thanks,
Mat
tails bootable usb
Date: 2017-11-27 05:19 pm (UTC)thanks for your help
shim
Date: 2018-05-17 02:19 am (UTC)others may have written and been trunk'd by the site. idk.
regardless, Thank You.