They are the translations of two posts that James Bottomley has taken on his blog. The first post was made on February 1 and is called "LCA2013 and Restructuring the Secure Boot"
I was quiet for a bit, so it's time to give an update on what's going on with the Linux Foundation's Secure Boot Loader (especially that it was featured at LCA2013). (Link to the slides)
The essence of the problem is that GregKH (kernel developer Greg Kroah-Hartman) discovered in early December that the proposed Pre-BootLoader would not work in its current form with Gummiboot. That was somewhat daunting because it meant that it was not fulfilling the Linux Foundation's mission of activating all bootloaders. In the research, the reason was simple: Gummiboot was created to demonstrate that you could make a small and simple bootloader that would take advantage of all the services available on the UEFI platform instead of being a massive link loader like GRUB. Unfortunately it means that you boot kernels using the BootServices-> LoadImage () function, which means that the kernel to be booted has to go through the secure boot checks on the UEFI platform. Originally the Pre-BootLoader, like shim (Mathew Garrett's bootloader), was written to use PE / Coff link loading to defeat secure boot checks. Unfortunately, it means that something run by the Pre-BootLoader must also use link loading to beat the secure boot checks on anything it wants to load and therefore Gummiboot, which is deliberately not a link loader, will not work under this scheme.
So I had to restructure and rewrite: The problem now went from "how to create a link loader signed by Microsoft that obeys their policies" to "how to enable all children of the boot loader to use the BootServices-> LoadImage () function of way to obey their policies. Fortunately, there is a way to intercept the UEFI platform signing infrastructure by installing your own architecture security protocol. Unfortunately, the platform initialization specification is not actually part of the UEFI specification, but thankfully it is implemented by every Windows 8 system you can find. The new architecture intercepts that protocol and adds its own security check. However, there is a second problem: While we are in the architecture security protocol callback, we do not necessarily own the UEFI system screen, making it completely impossible to do a user test to authorize the execution of the binary. Fortunately, there is a non-interactive way to do this and that is the SUSE Machine Owner Key (MOK) mechanism. Therefore, the Linux Foundation Pre-BootLoader now evolved to use standard MOK variables to store authorized binary hashes.
The upshot of all this is that you can now use the Pre-BootLoader with Gummiboot (just like it was done in the demo at LCA2013). To boot, you have to add 2 hashes: one for the Gummiboot itself and the other for the kernel that you want to boot, but in fact it is a good thing because now you have a single security policy controlling the entire boot sequence. The Gummiboot itself was also patched to recognize a crash due to secure boot and displays a message telling you which hash to enroll.
I will do a separate post explaining how the new architecture works, but I thought it would be better to explain what happened last month.
And this second post he did yesterday and is called "Launched the Linux Foundation Secure Boot System"
As promised, here is the Linux Foundation Secure Boot System. It was actually released to us by Microsoft on February 6, but with the travels, conferences, and meetings I didn't have time to validate everything until today. The files are:
PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Also create a bootable mini-USB image; (You have to install it on the USB using dd; the image has GPT partitions, so it uses the whole disk). It has an EFI shell where the kernel should be and uses gummiboot to load it. You can find it here (md5sum 7971231d133e41dd667a184c255b599f).To use the mini-USB image, you must enter the hashes for the loader.efi (in the \ EFI \ BOOT folder) and the shell.efi (in the root folder). It also includes a copy of KeyTool.efi, you have to enter the hash to run.
What happened to the KeyTool.efi? It was originally going to be part of our signed kit. However, during testing Microsoft discovered that due to a bug in one of the UEFI platforms, it could be used to remove the platform key programmatically, which would ruin the UEFI security system. Until we can solve this (we have the private vendor in the loop), they refused to sign the KeyTool.efi although you can authorize it by adding MOK variables if you want to run it.
Let me know how this goes because I'm interested in gathering feedback on what works and what doesn't. In particular, I am concerned that the security protocol override may not work on some platforms, so I particularly want to know if it does not work for them.
Sources:
http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/
http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
Decide if it is good or bad news.
Well, I can't see the long-term impact, but for me it will be my goal to acquire one of these http://blog.linuxmint.com/?p=2055
They are very expensive, I think.
There are companies that sell computers without a pre-installed operating system. Others allow you to choose between Ubuntu or others and send it to your home ready. You can also buy the parts and assemble it yourself and put the operating system you want.
In your city (GDL) there is a chain of computer stores that sell computers without a pre-installed operating system. You can put Linux on them.
There are always options. In this case, they are remote and very "hidden" from the common user. But for those of us who want Linux, there is, there is.
There are not so many options for users in Latin America since these "special" companies do not usually reach this far
awwnnn sad, sad…. that damn UEFI is a real problem
Report Error…. what happened? Why did I get the apple logo in my comments? I am using midori, but from ubuntu, not from a mac: /
Well, very simple, you must change the user agent.
These plugins are based on searching for a string (text string) in this case they look for your system in the user agent and the midori user agent has a text string that also has MacOS X, I don't remember if intel or Mac OSX or the two, but first find this string and relate it as if it were Mac. Some time ago I programmed a similar script in php and another javascript and this is solved from the script, seeing that it does not take anything after Mac OS X and sending that result to the midori variable, since it is the only thing that differentiates the user agent used by midori with that of Mac, or we can change it too.
Check this site with midori
http://whatsmyuseragent.com/
And the user agent has nothing to do with Linux
regards
«Carlos-Xfce
In your city (GDL) there is a chain of computer stores that sell computers without a pre-installed operating system. You can put Linux on them. "
At the time I looked and did not find, only a wholesaler who sold me netbooks without OS, but only that, no PC or laptop, only netbook.
Could you say the name of the chain?
If posting the name of the chain could be misinterpreted, and is considered spam, it would be good to wait for the administrators to give their opinion on it.