Our Planned Approach to Secure Boot
In this follow-on blog to UEFI Secure Boot, I will describe our plans towards UEFI Secure Boot. Note that when we say “SUSE”, we really mean two very distinct distributions – SUSE Linux Enterprise on one hand, and openSUSE on the other hand. The latter, being a community project, is rather independent in their decisions on how to address the issue – so the description below should be considered as the current Plan of Record for SUSE Linux Enterprise, but in the context of openSUSE, it can be a proposal for the community’s consideration only.
As explained in the previous installment of this series, UEFI Secure Boot is a useful technology, making it harder for attackers to hide a rootkit in the boot chain.
And at the same time, already the basics of its operation – establishing a single root of trust – conflict with the principles of Open Source development, which must be independent and distributed to work.
On top of that, there are a number of licensing and legal headaches waiting for anyone who wants to make use of Secure Boot in its default form. The GPL v3 anti-tivoization clause being one, another one being the wording of Microsoft’s SysDev contract that precludes the signing of GPLv3 binaries with a Microsoft-provided certificate.
Currently, the first desktop systems are shipping with Secure Boot support, and we expect it to become pervasive in all newly sold PCs toward the end of this year. And of course we expect all of them to be shipped with Microsoft’s Key Exchange Key (KEK) installed by default.
Some of these new machines will probably have a way to disable secure boot easily; in others it may be possible but cumbersome; and in still others it may be impossible without loss of other functionality.
Supporting UEFI Secure Boot essentially boils down to having a boot loader with a digital signature that the firmware recognizes as a trusted key, and in order to be useful to Enterprise customers, that key should be trusted by the firmware a priori, without requiring any manual intervention.
There are two ways of getting there. One is to work with hardware vendors to have them endorse a SUSE key which we then sign the boot loader with. The other way is to go through Microsoft’s Windows Logo Certification program to have the boot loader certified and have Microsoft recognize our signing key (i.e. have it signed with their KEK). We are currently evaluating both approaches, and may eventually even pursue both in parallel.
At the implementation layer, we intend to use the shim loader originally developed by Fedora – it’s a smart solution which avoids several nasty legal issues, and simplifies the certification/signing step considerably. This shim loader’s job is to load grub2 and verify it; this version of grub2 in turn will load kernels signed by a SUSE key only. We are
currently considering to provide this functionality with SLE11 SP3 on fresh installations with UEFI Secure Boot present.
Now it is probably clear why this approach offers the level of security that UEFI Secure Boot promises – there is an unbroken chain of verification, making sure only trusted and signed code gets executed prior to handing control to the Operating System kernel.
What isn’t clear is how this allows Open Source developers to run their own kernels, or bootloaders for that matter or how this complies with the GPL v3 license. In the next part of this series of blogs, we will explain how we intend to provide this with our version of the shim.
Related Articles
Jan 12th, 2023
SUSE Receives 15 Badges in the Winter G2 Report
Aug 21st, 2024
Comments
Thank you!
A fine start, and a ‘common sense’ approach for a common senseless situation. Look forward to reading more, specifically when it comes to openSUSE
I will disagree. The facts are simple: UEFI Secure Boot, as it stands now, is an ever more successful to keep free/open software out of computers.
“What isn’t clear is how this allows Open Source developers to run their own kernels”? No, it’s very clear: Open Source developers can’t run their own kernels if they want to run some later version of Windows as well. MS didn’t even care to hide that fact: they already require permanent UEFI Secure Boot on ARM. Do you really think they will stop at that? History shows they won’t.
The half-measures Red Hat, SUSE and others (basically bowing their heads to “the inevitable”) are applying are repeating a policy of appeasement that has been proven ultimately useless time and again.
Now you can pat the SUSE developers’ back all you want. This decision is wrong and they will find out sooner rather than later, I’m afraid.
Well, I don’t think so. Secure Boot is not Trusted Computing, for one.
On the other hand, there are a number of approaches that are within the UEFI spec that would allow the owner of the machine to run his own boot loader and kernel.
For instance, one approach would be to have the shim loader validate the signature on grub versus a key installed in the TPM. Only the legitimate owner of a machine can initialize the TPM and store (or generate) a key in it. A valid signature by a TPM-owned key would prove that the boot loader has been installed by the legitimate owner of the PC. This conforms to the goals of Secure Boot but still gives the owner of the hardware full control over what will run on it.
The problem with this approach is that setting up the TPM tends to be rather cumbersome in several BIOSes; plus you need UEFI drivers to actually talk to the TPM.
In the end, we came up with some equally effective but more straightforward approaches. Vojtech will provide the details on them shortly.
So no, Secure Boot is not the end of the free world. It just requires some creative thinking, and a lot of aspirin to figure out a way through the legal maze around it.
[…] Boot Vinícius Vieira 09/08/2012 0 wpa2a.script_load();Olaf Kirch, diretor de Engenharia do SUSE, escreveu em seu blog que sua equipe de desenvolvimento decidiu usar a solução do Projeto Fedora ao Secure Boot.Semanas […]
The GPL3 is not a licensing issue for signed keys, you simply need to provide instructions on how someone can generate their own keys, that’s all. See this podcast episode for a concise explanation: http://faif.us/cast/2012/jul/05/0x2D/
That is okay as long as the firmware allows the user to install those keys. Currently, we haven’t seen any machines that allow a “return to setup mode”, and frankly, I’d not hold my breath that a lot of them will.
The Microsoft certification requirements explicitly require that they do:
“Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: “Custom” and “Standard”. Custom Mode allows for more flexibility as specified in the following:
It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.
If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.
The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.”
[…] Кирч (Olaf Kirch), директор по разработке SUSE Linux, раскрыл планы по реализации поддержки режима безопасной […]
[…] Olaf Kirch de SUSE escribe en el blog, “En la capa de aplicación, tenemos la intención de utilizar el shim loader desarrollado originalmente por Fedora -. Es una solución inteligente que evita varios problemas legales desagradables, y simplifica el paso de certificación / firma considerablemente Este trabajo de este cargador de Shim consiste en cargar el grub2 y verificar est; esta versión de grub2 a su vez cargara kernels firmados por una clave única de SUSE. Estamos estudiando la posibilidad de proporcionar esta funcionalidad con SLE11 SP3 en instalaciones nuevas con la presencia de Secure Boot UEFI “.. […]
[…] SUSE Blog Ako Vam se dopada ovaj tekst lako ga možete podeliti sa […]
[…] began Olaf Kirch, director of the SUSE Linux Enterprise department in SUSE Engineering, in a blog post on Wednesday. “At the same time, already the basics of its operation–establishing a single […]
[…] began Olaf Kirch, director of the SUSE Linux Enterprise department in SUSE Engineering, in a blog post on Wednesday. “At the same time, already the basics of its operation–establishing a single […]
[…] began Olaf Kirch, director of the SUSE Linux Enterprise department in SUSE Engineering, in a blog post on Wednesday. “At the same time, already the basics of its operation–establishing a single […]
[…] began Olaf Kirch, director of the SUSE Linux Enterprise department in SUSE Engineering, in a blog post on Wednesday. “At the same time, already the basics of its operation–establishing a single […]
[…] Suse-Mitarbeiter Olaf Kirch erläutert den derzeitigen Stand der Diskussion der Nürnberger zum Thema UEFI Secure Boot in einen […]
Can I just turned off Security Boot on my _OWN_ PC?
[…] began Olaf Kirch, director of the SUSE Linux Enterprise department in SUSE Engineering, in a blog post on Wednesday. “At the same time, already the basics of its operation – establishing a […]
Hi
Translated this article. I will publish in my blog too.
Always mentioning the an linking original an the author, of course!
My particular point of view, as a simple user, I would like to be free to install what ever I want in my own PC!! Without the permission of any hardware or software company…
Maybe it’s necesary as a free software a powerful free and open Hardware…
Thank’s again for your work!! 😉
A spanish translation of this:
– http://victorhckinthefreeworld.wordpress.com/2012/08/15/suse-y-opensuse-propuestas-de-enfoque-ante-uefi-y-el-arranque-seguro/
[…] Desde su blog han comunicado que SUSE hará uso de la tecnología desarrollada por Fedora: At the implementation layer, we intend to use the shim loader originally developed by Fedora – it’s a smart solution which avoids several nasty legal issues, and simplifies the certification/signing step considerably. This shim loader’s job is to load grub2 and verify it; this version of grub2 in turn will load kernels signed by a SUSE key only. We are currently considering to provide this functionality with SLE11 SP3 on fresh installations with UEFI Secure Boot present. […]