[opensuse-project] UEFI Secure Boot
Olaf Kirch and Vojtech Pavlik, two SUSE colleagues of mine that are also kernel developers, have been looking with others at the UEFI situation and wrote up their findings and a proposal on what to do for openSUSE. We'll share here whatever they write, I guess they do a post a day for the next few days. First post is at: http://www.suse.com/blogs/uefi-secure-boot-overview/ I'm copied the text: In case you don’t know what this blog is talking about: UEFI is the “Unified Extensible Firmware Interface”, and “Secure Boot” is one of its more recent features that is generating a bit of a stir in the Open Source world. At SUSE, we have been looking at UEFI Secure Boot long and hard. On one hand, we agree that closing down some of the loopholes in the boot process is a worthwhile goal. For decades, we have accepted that this process has been one of the soft spots that are essentially unfixable without a major change in the BIOS. Now that this change is coming, we are ready to embrace it. And we’re also happy to see a much bigger change happening as part of this, which is the establishment of UEFI as the standard firmware on all x86 platforms. On the other hand, as a Linux company, we are seeing a number of issues that have been causing us quite some headaches, which we wanted to resolve before we publicly state our plans in this regard. In order to explain our concerns, let’s take a brief look at what Secure Boot really does, in a nutshell. In the world of UEFI, securing the bootstrapping process means establishing a chain of trust. The “platform” is the root of this chain of trust; I tend to think of it as the motherboard and the on-board firmware ROM. Or, put slightly differently, it’s the hardware vendor, and the chain of trust flows from that hardware vendor to the component manufacturers, the OS vendors, etc. On the legal side, this trust is established by a lot of contracts and other legal paperwork. On the level of bits and bytes, this trust is expressed via public key cryptography. The vendor puts a so-called Platform Key into the ROM, representing the root of trust. The trust relationships with operating system vendors and others is documented by signing their keys with the Platform Key. Finally, security is established by requiring that no code will be executed by the firmware unless it has been signed by one of these “trusted” keys – be it an OS boot loader, some driver located in the ROM of some PCI Express card, or be it an update of the firmware itself. Of course, one could make this a very long chain of trust, by requiring that everything that ever gets run on that machine be signed: the OS itself, the modules it loads, the binaries and shared libraries it loads, all the scripts executed by any random interpreter, and even the commands you type into a shell session. So obviously, that has to stop somewhere; and in the UEFI specification, that point is reached when the firmware hands control to the operating system. Essentially, if you want to use Secure Boot, you need to have your OS loader signed with a key trusted by the firmware, and you need the OS loader to verify that the kernel it loads can be trusted. Admittedly, this is glossing over quite some details – but that is of no real importance for this discussion. The crux of the matter is that this conflicts with the way the Open Source community has been developing code for several decades now. The Open Source movement began as an act of emancipation from the operating system vendors of that time. Open Source was and is about Freedom, not in a dogmatic, but really in some very practical sense. The Linux community is where it is today because people could just start their own distribution, build their own boot loader and kernel, and grow a community. It is thriving the way it is thriving today because there are thousands of people around the globe who rebuild their kernel ten times a day to fix bugs, to add enhancements, or to run their test harness on the latest set of changes. And it will only continue to thrive in this way if we keep it that way. From this point of view, Secure Boot is very much at odds with the Linux development model. Just for the record, I do not think this is a conspiracy, or a sinister attempt to kill Linux. That’s not going to happen. But while Secure Boot can be a significant improvement for many, it definitely creates obstacles for the Linux community. Granted, the Windows 8 Logo certification requires that BIOS vendors should allow users to turn off Secure Boot on x86 platforms, and we have hope that all BIOS vendors will actually implement this in a way that works well for Linux developers. But ideally, Linux developers should not be required to switch off a security feature in order to run their operating system. Thus, over the past months, our guiding questions when dealing with Secure Boot have been, how can we make it work for our customers, and how can we reconcile the requirements of Secure Boot with the needs of the Linux community. We plan to continue this series of blog postings soon with an overview of how we intend to support Secure Boot in SUSE Linux Enterprise, and what solutions we propose to the openSUSE community. -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday 07 August 2012 20.04:35 Andreas Jaeger wrote:
Olaf Kirch and Vojtech Pavlik, two SUSE colleagues of mine that are also kernel developers, have been looking with others at the UEFI situation and wrote up their findings and a proposal on what to do for openSUSE. We'll share here whatever they write, I guess they do a post a day for the next few days.
First post is at: http://www.suse.com/blogs/uefi-secure-boot-overview/
I'm copied the text:
Thanks all for that kind of quality paper. Will be easy to correctly inform people with those explanations. -- Bruno Friedmann openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-08-07 21:31, Bruno Friedmann wrote:
On Tuesday 07 August 2012 20.04:35 Andreas Jaeger wrote:
Olaf Kirch and Vojtech Pavlik, two SUSE colleagues of mine that are also kernel developers, have been looking with others at the UEFI situation and wrote up their findings and a proposal on what to do for openSUSE. We'll share here whatever they write, I guess they do a post a day for the next few days.
First post is at: http://www.suse.com/blogs/uefi-secure-boot-overview/
I'm copied the text:
Thanks all for that kind of quality paper. Will be easy to correctly inform people with those explanations.
Yes, absolutely. :-) - -- Cheers / Saludos, Carlos E. R. (from 12.1 "Asparagus" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAheKMACgkQU92UU+smfQVEXgCePfBdyUBXf4lc7lo5MEztD14S pQkAnA9o2Rwo9YzKggeDQXU5n27SYLHJ =lGfG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 2012-08-07 22:20:51 (+0200), Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-08-07 21:31, Bruno Friedmann wrote:
On Tuesday 07 August 2012 20.04:35 Andreas Jaeger wrote:
Olaf Kirch and Vojtech Pavlik, two SUSE colleagues of mine that are also kernel developers, have been looking with others at the UEFI situation and wrote up their findings and a proposal on what to do for openSUSE. We'll share here whatever they write, I guess they do a post a day for the next few days.
First post is at: http://www.suse.com/blogs/uefi-secure-boot-overview/
I'm copied the text:
Thanks all for that kind of quality paper. Will be easy to correctly inform people with those explanations.
Yes, absolutely. :-)
Probably the best writeup on the topic up to now -- Olaf, Vojtech, keep up the good work, and thanks for doing it :) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf
Part 2 is out at http://www.suse.com/blogs/uefi-secure-boot-plan/, Andreas Text copied: "Our Planned Approach to Secure Boot August 8, 2012 10:13 am 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." -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Looks good so far. The key (pun intended) is to get lawyers,
accountants and software engineers working together towards a common
goal. ;-)
On Wed, Aug 8, 2012 at 3:38 AM, Andreas Jaeger
Part 2 is out at http://www.suse.com/blogs/uefi-secure-boot-plan/,
Andreas
Text copied: "Our Planned Approach to Secure Boot
August 8, 2012 10:13 am
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."
-- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://j.mp/QCsXOr Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Third post in the serious - with a picture that I'm not attaching. Post is at: www.suse.com/blogs/uefi-secure-boot-details/ Andreas In the previous posts, UEFI Secure Boot and Our Planned Approach to Secure Boot, Olaf Kirch has introduced you into the topic of UEFI Secure Boot and the basics of our approach to implementing it in SUSE. In this post, I’ll lead you through the technical details of our Secure Boot plan. So be prepared for this post to be rather detailed. And technical. The goal of Secure Boot is to prevent malware from hiding embedded in the boot chain by performing a verification of every executed component starting with a fresh reboot of the whole platform. To achieve its goal, Secure Boot must prevent any modification of the verification process, the keys, or any other variables by untrusted code or untrusted entities. Examples of an untrusted entity is a hacker who has penetrated the system through an unpatched security hole in the operating system. There are two types of trusted users: First, those who hold the keys. The Platform Key (PK) allows almost everything. The Key Exchange Key (KEK) allows all a PK can except changing the PK. Second, anyone with physical access to the machine. A user with physical access can reboot the machine, and configure UEFI. UEFI offers two types of variables to cater to the needs of those users: The first is the so called “Authenticated Variables,” which can be updated from both within the boot process (the so called Boot Services Environment) and the running OS, but only when the new value of the variable is signed with the same key that the old value of the variable was signed. And they can either only be appended to or changed to a value with a higher serial number. The second is the so called “Boot Services Only Variables.” These variables are accessible to any code that runs during the boot process. After the boot process ends and before the OS starts, the bootloader must call the ExitBootServices() call. After that, these variables are no longer accessible, the OS can’t touch them. The various UEFI key lists are part of of the first type of variable, as this allows on-line updating, adding and blacklisting of keys, drivers and firmware fingerprints. It’s the second type of variable, the “Boot Services Only Variable” that will help us in our quest for an implementation of Secure Boot that is both secure and open source friendly. And compatible with GPLv3. Illustration of the verification process As Olaf explained in the last post, we start with a shim, based on the Fedora shim, signed by either a certificate signed by the SUSE KEK or a Microsoft-issued certificate, based on what KEKs are available in the UEFI key database on the system.This allows the shim to load and execute. The shim then goes on to verify that the GRUB2 bootloader it wants to load is trusted. It will not use the SUSE KEK nor the Microsoft cert for this. In a default situation GRUB2 bootloader will use an independent SUSE certificate embedded in the body of the shim. In addition, the shim will allow to “Enroll” additional keys, overriding the default SUSE key. Let’s call them “Machine Owner Keys” or MOKs for short. The enrollment process begins by rebooting the machine and interrupting the boot process (e.g, pressing a key) when the shim loads. The shim will then go into enrollment mode, allowing the user to replace the default SUSE key with keys from a file on the boot partition. If the user chooses to do so, the shim will then calculate a hash of that file and put the result in a “Boot Services Only” variable. This allows it to detect any change of the file made outside of Boot Services and thus avoid the tampering with the list of user approved MOKs. An important aspect to remember is that all of this happens during boot time, only verified code is executing now. Therefore, only a user present at the console can say, “I want to use my own set of keys.” It can’t be malware or a hacker with remote access to the OS because hackers or malware can only change the file, but not the hash stored in the “Boot Services Only” variable. GRUB2, once loaded and verified by the shim, will call back to the shim when it wants to verify the kernel – to avoid duplication of the verification code. GRUB 2 will use the same list of MOKs for this and load the kernel. And that’s it. All a kernel or grub developer needs to work on is improving the kernel or the bootloader. Install a new set of keys and authorize them by being physically present during the first reboot. Also, thanks to MOKs being a list and not just a single MOK, you can make the shim trust keys from several different vendors, allowing dual and multi-boot from the grub2 bootloader. In the end the real implementation may be a little bit more complicated – for example password-protecting the MOK authorization feature to allow secure authenticated updating of the MOK list from within the OS – but this is the gist of it. And since you can freely modify GRUB2 and your kernel as an owner of a machine, you are happy and so is GPLv3 that the machine didn’t get tivoized. You may be wondering whether this goes against the UEFI specification or Microsoft Win8 Logo requirements or any of the associated contracts. I don’t think so – even the UEFI specification allows, but doesn’t mandate, that a UEFI implementation allow a user authorize EFI code with an invalid signature by adding a hash to a special variable. And the Linux Foundation has asked vendors to make sure to include a way of clearing the PK to allow the user to enroll their own set of keys. Our approach is just making sure that a feature like this is available everywhere. To keep the “PC” a free platform. -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, Aug 9, 2012 at 4:41 PM, Andreas Jaeger
Let’s call them “Machine Owner Keys” or MOKs for short.
...
The second is the so called “Boot Services Only Variables.” These variables are accessible to any code that runs during the boot process. After the boot process ends and before the OS starts, the bootloader must call the ExitBootServices() call. After that, these variables are no longer accessible, the OS can’t touch them.
...
An important aspect to remember is that all of this happens during boot time, only verified code is executing now. Therefore, only a user present at the console can say, “I want to use my own set of keys.” It can’t be malware or a hacker with remote access to the OS because hackers or malware can only change the file, but not the hash stored in the “Boot Services Only” variable.
I want to make sure I understand. So, if I'm compiling code on my own box I install a MOK validation key via the console (prior to the ExitBootServices() call) and I use my MOK signing key to sign any kernels I build. That seems easy enough. But what if I want to compile a kernel for a physically remote computer, what do I do? I'm thinking of the situation of a rented 1u (or similar) box far from my location. I've rented those before that I could have the provider dump a default OS (opensuse/SUSE, fedora/Redhat) on and then I take it from there. As part of the provisioning process, does the provider now need to create a MOK for that machine and install it, then give me the signing cert so I can build kernels for the box. Will the same thing be true of a Redhat provisioned remote server? If all of linux has a similar provisioning scheme, it should fly. If the openSUSE/SUSE provisioning scheme is unique, I suspect a lot non-compliance on the part of remote server providers. Thanks Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, 09 Aug 2012 18:17:30 -0400, Greg Freemyer wrote:
I'm thinking of the situation of a rented 1u (or similar) box far from my location. I've rented those before that I could have the provider dump a default OS (opensuse/SUSE, fedora/Redhat) on and then I take it from there.
In such a situation Secure Boot could be disabled since the OS doesn't require it to boot. The only time you'd need to use this is if the system dual-booted Linux and Windows 8, because the Windows 8 installation wouldn't boot if Secure Boot was disabled on the hardware. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, Aug 9, 2012 at 3:52 PM, Jim Henderson
On Thu, 09 Aug 2012 18:17:30 -0400, Greg Freemyer wrote:
I'm thinking of the situation of a rented 1u (or similar) box far from my location. I've rented those before that I could have the provider dump a default OS (opensuse/SUSE, fedora/Redhat) on and then I take it from there.
In such a situation Secure Boot could be disabled since the OS doesn't require it to boot. The only time you'd need to use this is if the system dual-booted Linux and Windows 8, because the Windows 8 installation wouldn't boot if Secure Boot was disabled on the hardware.
Jim
Won't servers usually be sold as part of a fully-configured and licensed package from major vendors / hardware-software partnerships? Like IBM-Red Hat, IBM-SUSE, Dell-Canonical, etc.? This is a case that actually matters, and for Attachmate/SUSE not to have a solution when Red Hat and Canonical do is a serious competitive disadvantage!
-- Jim Henderson Please keep on-topic replies on the list so everyone benefits
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
-- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://j.mp/QCsXOr Data is the new coal - abundant, dirty and difficult to mine. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, 09 Aug 2012 16:13:09 -0700, M. Edward (Ed) Borasky wrote:
Won't servers usually be sold as part of a fully-configured and licensed package from major vendors / hardware-software partnerships?
I have never, ever, ever seen a server that was dual-boot outside of a lab. If Windows isn't involved, UEFI's Secure Boot can and should be disabled.
Like IBM-Red Hat, IBM-SUSE, Dell-Canonical, etc.? This is a case that actually matters, and for Attachmate/SUSE not to have a solution when Red Hat and Canonical do is a serious competitive disadvantage!
Only for those who believe that Secure Boot being enabled for anything other than Microsoft's Windows logo program provides any sort of significant advantage. If Windows isn't involved on the hardware, then disable Secure Boot and go on with life. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Jim Henderson wrote:
On Thu, 09 Aug 2012 16:13:09 -0700, M. Edward (Ed) Borasky wrote:
Won't servers usually be sold as part of a fully-configured and licensed package from major vendors / hardware-software partnerships?
I have never, ever, ever seen a server that was dual-boot outside of a lab.
If Windows isn't involved, UEFI's Secure Boot can and should be disabled.
Exactly. I can't help thinking that that is not really much of a use case? -- Per Jessen, Zürich (16.8°C) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
* Per Jessen
Jim Henderson wrote:
On Thu, 09 Aug 2012 16:13:09 -0700, M. Edward (Ed) Borasky wrote:
Won't servers usually be sold as part of a fully-configured and licensed package from major vendors / hardware-software partnerships?
I have never, ever, ever seen a server that was dual-boot outside of a lab.
If Windows isn't involved, UEFI's Secure Boot can and should be disabled.
Exactly. I can't help thinking that that is not really much of a use case?
Ensuring the integrity of the boot process by preventing the firmware, boot loader or kernel from being trojaned, in particular in combination with disk encryption. Note that this functionality is already available in openSUSE today via TrustedGRUB if you have a TPM. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
I'm forwarding the following from Vojtech since I forgot to CC Vojtech previously;( Andreas Greg, Creating the key pair yourself and providing only the signature verification cerificate to the provider before they provision your server seems like a safer process, but since the provider has physical access, you have to trust them anyway, so them having a copy of the signing key doesn't make much difference. Better providers will give you access to a remote console of your system, including to the UEFI boot process and that's as good as being physically present. And to the last question: Yes, I'm talking to others about adopting a common scheme and so far the feedback has been positive. Vojtech -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 10/08/12 06:41, Andreas Jaeger wrote:
Third post in the serious - with a picture that I'm not attaching. Post is at: www.suse.com/blogs/uefi-secure-boot-details/
Andreas
In the previous posts, UEFI Secure Boot and Our Planned Approach to Secure Boot, Olaf Kirch has introduced you into the topic of UEFI Secure Boot and the basics of our approach to implementing it in SUSE. In this post, I’ll lead you through the technical details of our Secure Boot plan. So be prepared for this post to be rather detailed. And technical.
Technical is right :-) . I am trying to follow the discussion but at the moment I have other things straining what I carelessly call a "brain" and therefore my question may already be answered by what has been written so far on this UEFI matter. My question is: what would happen when one should use - as I did today - a bootable CD like System Rescue Disc? (I am guessing that if this were the openSUSE installation DVD then it would have some code in it which would allow it to boot without problems.) [.........] BC -- Using openSUSE 12.2 x86_64 KDE 4.8.4 & kernel 3.5.0-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Quoting Andreas Jaeger
Third post in the serious - with a picture that I'm not attaching. Post is at: www.suse.com/blogs/uefi-secure-boot-details/
Dear Andreas, and especially also Olaf and Vojtech! Thank you very much for this series of blog posts! I appreciate that somebody actually first took the time to understand the matter, analyze it, come up with a proposal and then starts writing about it. The approach you present indeed looks like a very good compromise. I'm sure we ALL agree that 'security' for an own computer is crucial; maybe less on the 'hobby cellar server', but for the working horse we all have it is. The proposed solution seems to go the right way, allowing the user to introduce an own set of keys (thus, remaining the 'owner' and 'decider' over his machine, as well as also having the security UEFI is supposed to provide. I'm looking forward to the implementation of this! Do we already have an outlined schedule of when something like this shall be available? (most of it of course is done, based on Fedoras work, and the blog series seems to target SLE11SP3... when would that be?) Best regards, Dominique -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Thank's to Olaf for let me publish a spanish translation of his article in my blog. The original: - http://www.suse.com/blogs/uefi-secure-boot-overview/ The translation - http://victorhckinthefreeworld.wordpress.com/2012/08/13/suse-opensuse-ante-u... I would like to trnaslate the other 2 articles about this. I'm not sure but I will try!! ;) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
I have made a spanish translation of the 2nd article written by Olaf - Original: http://www.suse.com/blogs/uefi-secure-boot-plan/ - My translation: http://victorhckinthefreeworld.wordpress.com/2012/08/15/suse-y-opensuse-prop... Bye -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, 13 Aug 2012, Dominique Leuenberger a.k.a DimStar wrote:
I'm looking forward to the implementation of this! Do we already have an outlined schedule of when something like this shall be available? (most of it of course is done, based on Fedoras work, and the blog series seems to target SLE11SP3... when would that be?)
Next year (2013) in a month whose name starts with a J and which
is more than half a year out. :-)
In other words, late Q2, early Q3 is the current thinking.
Gerald
--
Dr. Gerald Pfeifer
participants (13)
-
Andreas Jaeger -
Basil Chupin -
Bruno Friedmann -
Carlos E. R. -
Dominique Leuenberger a.k.a DimStar -
Gerald Pfeifer -
Greg Freemyer -
Guido Berhoerster -
Jim Henderson -
M. Edward (Ed) Borasky -
Pascal Bleser -
Per Jessen -
Victor hck