Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
The Reg has a story on this from a blog post by Red Hat. It may be worth a read: http://www.theregister.co.uk/2012/01/18/windows_8_linux_secure_boot/
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 4:30 PM, Florian Philipp wrote: > Am 17.06.2012 20:56, schrieb Sascha Cunz: >> I was under the impression that it should at least help in that scenario. >> OTOH, if it takes a compromised system or physical access to the machine in >> order to manipulate the boot sequence, then I no longer understand what the >> boot sequence in such a system must be protected against (Assuming that the >> primary reason for boot sequence manipulation is to later on compromise the >> system). >> > > Well, it does help, especially when you also prevent changing UEFI > settings with a password. However, there are so many variables and > possibilities when talking about attacks on physically accessible > systems, that you're usually screwed anyway. I'd view secure boot as complementary to TPM. TPM keeps somebody with physical access from being able to access important information on your computer, since that data would be encrypted and the keys would not be surrendered by the TPM module without a proper chain of trust. TPM is potentially more secure, although it has a fatal flaw in that if the OS is compromised then the keys can be obtained (since the OS needs the keys to access the disk) and a trojan can be installed on the bootloader. That trojan is difficult to remove or even detect even if you update your virus scanners/etc. Secure boot keeps trojans out of the early boot chain, making them easier to clean up once your system is further updated. Secure boot is also somewhat easier to implement, and a bit more recoverable if things go wrong. If you're using TPM and trusted grub and all that, then if you mess up your trusted boot chain then you may never get back the contents of your drive, unless you kept a copy of various keys elsewhere. Rich
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 17.06.2012 20:56, schrieb Sascha Cunz: > On Sunday, 17. June 2012 20:00:51 Florian Philipp wrote: >> Am 17.06.2012 19:34, schrieb Sascha Cunz: >>> [...] >>> It doesn't. It's just a very long wooden fence; you just didn't find the hole yet. >>> >>> Given the fact that the keys in the BIOS must somehow get there and it >>> must >>> also be able to update them (how to revoke or add keys else?). >>> >>> Unless this is completely done in hardware, there must be a software doing >>> it. Software can - by design - be reverse engineered; in some countries >>> even legally without any further agreement or license. >>> >>> So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on >>> this blob of software - at some point it must be readable from the >>> processor, so you have to provide the mechanisms to verify signs, undo >>> encryption etc somewhere (either in hardware or another software). >>> >>> Even if you somehow manage to embed all of this in the hardware stack, it >>> would still require some kind of interface to get updated / revoked keys >>> to >>> operate on. >>> >>> It's not a matter of *if this can* be broken by someone who cares, it's a >>> matter of *how long does it take* for someone who cares to break it. >>> >>> In the end, this is just another kind of "seems to be secure for a day or >>> two". Admittedly a complex one - but there will always be a "kid in a >>> garage" that is able to set everyone else out of business. >>> >>> SaCu >> >> Okay, a few points here: >> >> First: On an abstract level, the key innovation in Secure Boot and >> driver signing is that it establishes a trust relationship between >> platform owner and platform firmware (using a so called Platform Key) as >> well as trust between operating system and platform firmware (using Key >> Exchange Keys). > > You've said yourself, that "some removable media might not require > signatures" > in order to boot. Well, if that is the case, then isn't this defeating the > whole point of Secure Boot at that stage? > No. If that was the case, then UEFI shouldn't allow deactivating Secure Boot, should it? Secure Boot's primary purpose is to prevent malware from installing itself into the bootloader or (by extension) the kernel image. >> Under the assumption that the implementation is correct, nothing on the >> operating system level can inject drivers, boot loaders or whatever else >> into the firmware unless it is properly signed. The platform will not >> allow anything unless it is bit-by-bit verified to come from the >> platform owner or a trusted third party. The recommended algorithms for >> signing and verifying code are SHA-256 and RSA-2048. Good luck breaking >> that in "a day or two"! >> >> Second point: Secure Boot is not designed to protect against an attacker >> with physical access to the machine. So you can leave your soldering >> iron and memory stick at home when you try to prove that Secure Boot can >> be broken. > > I was under the impression that it should at least help in that scenario. > OTOH, if it takes a compromised system or physical access to the machine in > order to manipulate the boot sequence, then I no longer understand what the > boot sequence in such a system must be protected against (Assuming that the > primary reason for boot sequence manipulation is to later on compromise the > system). > Well, it does help, especially when you also prevent changing UEFI settings with a password. However, there are so many variables and possibilities when talking about attacks on physically accessible systems, that you're usually screwed anyway. Again, the point is that malware, even if it gets temporary access to your system, even if it gets root access, cannot install itself into the boot process. It cannot persist in kernel space. >> Third point: Of course Secure Boot will be broken! A mainboard maker >> will screw up, there will be a bug in the specs or RSA will be broken. >> And when one of these happens, it will be fixed. Plain and simple. We >> didn't abandon SSL just because version 1 and 2 were broken. Why should >> we abandon Secure Boot? > > "Plain and simple" here probably means, that all (at least many) sold system > up to that date are downgraded to "unsecure". Not every user out there is > reachable by any channel telling that it is just now a hard requirement to > update the system - and even getting the message to the user won't cause 100% > of the reached users to go that upgrade path. > Yes, you are right here. But ultimately, any bugs will be fixed. Even if it means waiting for the next device generation. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Sascha Cunz writes: > You've said yourself, that "some removable media might not require > signatures" > in order to boot. Well, if that is the case, then isn't this defeating the > whole point of Secure Boot at that stage? Not necessarily. As has been stated previously, secure boot is not intended to protect against an attacker who has physical access. So even if allowing boot from removable media, it does protect against malware which corrupts/infects the hard drive boot image.
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sunday, 17. June 2012 20:00:51 Florian Philipp wrote: > Am 17.06.2012 19:34, schrieb Sascha Cunz: > > [...] > > > >> It doesn't. It's just a very long wooden fence; you just didn't find > >> the hole yet. > > > > Given the fact that the keys in the BIOS must somehow get there and it > > must > > also be able to update them (how to revoke or add keys else?). > > > > Unless this is completely done in hardware, there must be a software doing > > it. Software can - by design - be reverse engineered; in some countries > > even legally without any further agreement or license. > > > > So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on > > this blob of software - at some point it must be readable from the > > processor, so you have to provide the mechanisms to verify signs, undo > > encryption etc somewhere (either in hardware or another software). > > > > Even if you somehow manage to embed all of this in the hardware stack, it > > would still require some kind of interface to get updated / revoked keys > > to > > operate on. > > > > It's not a matter of *if this can* be broken by someone who cares, it's a > > matter of *how long does it take* for someone who cares to break it. > > > > In the end, this is just another kind of "seems to be secure for a day or > > two". Admittedly a complex one - but there will always be a "kid in a > > garage" that is able to set everyone else out of business. > > > > SaCu > > Okay, a few points here: > > First: On an abstract level, the key innovation in Secure Boot and > driver signing is that it establishes a trust relationship between > platform owner and platform firmware (using a so called Platform Key) as > well as trust between operating system and platform firmware (using Key > Exchange Keys). You've said yourself, that "some removable media might not require signatures" in order to boot. Well, if that is the case, then isn't this defeating the whole point of Secure Boot at that stage? > Under the assumption that the implementation is correct, nothing on the > operating system level can inject drivers, boot loaders or whatever else > into the firmware unless it is properly signed. The platform will not > allow anything unless it is bit-by-bit verified to come from the > platform owner or a trusted third party. The recommended algorithms for > signing and verifying code are SHA-256 and RSA-2048. Good luck breaking > that in "a day or two"! > > Second point: Secure Boot is not designed to protect against an attacker > with physical access to the machine. So you can leave your soldering > iron and memory stick at home when you try to prove that Secure Boot can > be broken. I was under the impression that it should at least help in that scenario. OTOH, if it takes a compromised system or physical access to the machine in order to manipulate the boot sequence, then I no longer understand what the boot sequence in such a system must be protected against (Assuming that the primary reason for boot sequence manipulation is to later on compromise the system). > Third point: Of course Secure Boot will be broken! A mainboard maker > will screw up, there will be a bug in the specs or RSA will be broken. > And when one of these happens, it will be fixed. Plain and simple. We > didn't abandon SSL just because version 1 and 2 were broken. Why should > we abandon Secure Boot? "Plain and simple" here probably means, that all (at least many) sold system up to that date are downgraded to "unsecure". Not every user out there is reachable by any channel telling that it is just now a hard requirement to update the system - and even getting the message to the user won't cause 100% of the reached users to go that upgrade path. SaCu
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 17.06.2012 19:34, schrieb Sascha Cunz: > [...] > >> It doesn't. It's just a very long wooden fence; you just didn't find >> the hole yet. > > Given the fact that the keys in the BIOS must somehow get there and it must > also be able to update them (how to revoke or add keys else?). > > Unless this is completely done in hardware, there must be a software doing > it. > Software can - by design - be reverse engineered; in some countries even > legally without any further agreement or license. > > So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on > this blob of software - at some point it must be readable from the processor, > so you have to provide the mechanisms to verify signs, undo encryption etc > somewhere (either in hardware or another software). > > Even if you somehow manage to embed all of this in the hardware stack, it > would still require some kind of interface to get updated / revoked keys to > operate on. > > It's not a matter of *if this can* be broken by someone who cares, it's a > matter of *how long does it take* for someone who cares to break it. > > In the end, this is just another kind of "seems to be secure for a day or > two". Admittedly a complex one - but there will always be a "kid in a garage" > that is able to set everyone else out of business. > > SaCu > Okay, a few points here: First: On an abstract level, the key innovation in Secure Boot and driver signing is that it establishes a trust relationship between platform owner and platform firmware (using a so called Platform Key) as well as trust between operating system and platform firmware (using Key Exchange Keys). Under the assumption that the implementation is correct, nothing on the operating system level can inject drivers, boot loaders or whatever else into the firmware unless it is properly signed. The platform will not allow anything unless it is bit-by-bit verified to come from the platform owner or a trusted third party. The recommended algorithms for signing and verifying code are SHA-256 and RSA-2048. Good luck breaking that in "a day or two"! Second point: Secure Boot is not designed to protect against an attacker with physical access to the machine. So you can leave your soldering iron and memory stick at home when you try to prove that Secure Boot can be broken. Third point: Of course Secure Boot will be broken! A mainboard maker will screw up, there will be a bug in the specs or RSA will be broken. And when one of these happens, it will be fixed. Plain and simple. We didn't abandon SSL just because version 1 and 2 were broken. Why should we abandon Secure Boot? Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 07:06:16PM +0200, Michał Górny wrote: > On Sun, 17 Jun 2012 09:55:35 -0700 > Greg KH wrote: > > > On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote: > > > 2. What happens if, say, your bootloader is compromised? > > > > And how would this happen? Your bootloader would not run. > > Yes. I'm asking what happens next. Is there an easy way to replace it? I do not know, you need to test this on a UEFI secure boot system to see what happens. > Or is your computer bricked until you run some other bootloader to > replace the compromised one? Probably. > > > 3. What happens if the machine signing the blobs is compromised? > > > > So, who's watching the watchers, right? Come on, this is getting > > looney. > > I'm just pointing out that this simply relies on trusting people. Much > like not having those signatures. Of course, this is life, and should not be anything "new" to you or anyone else. And before you get upset, do you trust the "people" who implemented the firmware in your processor and I/O controllers? This argument is not one that is worth discussing. greg k-h
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 1:34 PM, Sascha Cunz wrote: > > Given the fact that the keys in the BIOS must somehow get there and it must > also be able to update them (how to revoke or add keys else?). Based on what I've read the keys are stored in flash. The flash module itself is protected. There are a number of ways to implement something like this fairly securely. The simplest is to have an unprotected area of the flash that the OS can write to. Upon bootup the firmware looks in this area for a signed message. If the message is signed by a trusted source, then the firmware interprets it as instructions to update itself, add/remove keys, or whatever. Then before booting the OS the firmware sets the protect flag on the protected area of flash that is only unset by a hardware reset. The only software exploit against something like this is to find a bug in the code that inspects the flash (overflow/etc) to trick it into running an unsigned blob. There are also hardware attacks, like bypassing flash protection hardware, directly accessing flash, or controlling what shows up on the data bus when the CPU tries to read the firmware. Any of these can be made fairly difficult, and extreme case being how modern gaming consoles work (flash embedded in CPU, and so on). > > Unless this is completely done in hardware, there must be a software doing it. > Software can - by design - be reverse engineered; in some countries even > legally without any further agreement or license. With the scheme above no software need be distributed that contains any information useful for anything other than a replay attack. The blob would be signed prior to distribution. You could read the code that loads it into the flash, but that need not be kept secret. You can load whatever you want into the flash and it won't matter unless it is signed. If the hardware is fancy enough you could even update settings without having to reboot, and again unless the hardware isn't done right you're not going to be able to get around it without tapping busses/etc. Rich
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 17.06.2012 19:10, schrieb Michał Górny: > On Sun, 17 Jun 2012 12:56:34 -0400 > Matthew Finkel wrote: > >> On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny >> wrote: >>> 1. How does it increase security? >>> >> This removed a few vectors of attack and ensures your computer is only >> bootstrapped by and booted using software you think is safe. By using >> any software we don't write, we make a lot of assumptions. > > I agree that it removes a few vectors of attack. But this doesn't > necessarily mean the system is more secure. It has one vulnerability > less but let's not get overenthusiastic. > > I'm basically trying to point out that a single solution like that can > do more evil than good if people will believe it's perfect. > I think I now understand your train of thought. But I don't think anyone implied that Secure Boot solves each and every security issue. What it does, however, is impose new hurdles for malware authors. Therefore I don't see a reason not to use it as long as the inconveniences and limitations it imposes are acceptable for my particular use case. >>> 3. What happens if the machine signing the blobs is compromised? >>> >> See above. But also, a compromised system wouldn't necessarily mean >> the blobs would be compromised as well. In addition, ideally the >> priv-key would be kept isolated to ensure a compromise would be >> extremely difficult. > > In my opinion, if a toolchain is quietly compromised, everything built > on the particular machine can be compromised. And signed. I doubt that > someone will check bit-exact machine code of the toolchain > and operating system before starting to sign packages. > Just because you cannot rule out bugs doesn't mean you shouldn't use security enhancing systems. Don't tell me you open telnet for root access to your machines just because you cannot rule out the chance that SSH is compromised or someone compromised the SSH source code you downloaded from the Gentoo mirrors. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
[...] > It doesn't. It's just a very long wooden fence; you just didn't find > the hole yet. Given the fact that the keys in the BIOS must somehow get there and it must also be able to update them (how to revoke or add keys else?). Unless this is completely done in hardware, there must be a software doing it. Software can - by design - be reverse engineered; in some countries even legally without any further agreement or license. So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on this blob of software - at some point it must be readable from the processor, so you have to provide the mechanisms to verify signs, undo encryption etc somewhere (either in hardware or another software). Even if you somehow manage to embed all of this in the hardware stack, it would still require some kind of interface to get updated / revoked keys to operate on. It's not a matter of *if this can* be broken by someone who cares, it's a matter of *how long does it take* for someone who cares to break it. In the end, this is just another kind of "seems to be secure for a day or two". Admittedly a complex one - but there will always be a "kid in a garage" that is able to set everyone else out of business. SaCu
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 17.06.2012 19:06, schrieb Michał Górny: > On Sun, 17 Jun 2012 09:55:35 -0700 > Greg KH wrote: > >> On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote: [...] > >>> 3. What happens if the machine signing the blobs is compromised? >> >> So, who's watching the watchers, right? Come on, this is getting >> looney. > > I'm just pointing out that this simply relies on trusting people. Much > like not having those signatures. > If you are so much worried about it, UEFI allows you to remove all keys and just add your own. That way, only code signed by you will be executed. And in the standard case, well, it is just as good (or bad) as the SSL certificate business. It's not a perfect system but it is better than having everyone using self-signed certificates or none at all. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Greg KH wrote: > On Sat, Jun 16, 2012 at 06:37:41PM -0500, Steev Klimaszewski wrote: >> Just picking a random response to reply to. I'm not speaking >> officially, however, I'm pretty sure we at Genesi aren't going to pay >> Microsoft in order to boot our own boards. > If you don't want your boards to be Windows 8 certified, then you are > fine. Otherwise, you have to follow their guidelines, which I don't > think requires paying them any money if you want to run Windows 8. > > Also, as these are "your own boards", you control the BIOS, so you don't > even have to implement UEFI, or, if you do, you can control what keys > are installed in the BIOS by default. > > So I don't understand the issue here, please explain. > > greg k-h > > . > I'm glad you said that. If I was going to have to pay M$ to run Linux, I was thinking of shooting them with laser eyes or something. I have no plans to ever support M$ in any shape, form or fashion. Period. Thing is, they will likely try to make it so you can't disable it eventually. Some politician will try to make it a law if nothing else. After all, politicians are clueless anyway. Reminds me of chickens and it raining. :/ Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS="--quiet-build=n"
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 1:06 PM, Michał Górny wrote: > On Sun, 17 Jun 2012 09:55:35 -0700 > Greg KH wrote: > >> On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote: >> > 2. What happens if, say, your bootloader is compromised? >> >> And how would this happen? Your bootloader would not run. > > Yes. I'm asking what happens next. Is there an easy way to replace it? > Or is your computer bricked until you run some other bootloader to > replace the compromised one? My understanding is that there are a few options here. One is to simply re-image the system, either directly (as any vendor does), or after booting off of removable media. I'd have to re-read the spec but some of those might not require signatures, and in any case ones with valid signatures should be available. You can of course disable secure boot or go into custom mode as well which lets you do whatever you want until you have the system back in a bootable state. If you're running Windows 8 I believe they plan to have a recovery partition as well, which will be signed and bootable and which is designed to recover the OS. Rich
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, 17 Jun 2012 12:56:34 -0400 Matthew Finkel wrote: > On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny > wrote: > > 1. How does it increase security? > > > This removed a few vectors of attack and ensures your computer is only > bootstrapped by and booted using software you think is safe. By using > any software we don't write, we make a lot of assumptions. I agree that it removes a few vectors of attack. But this doesn't necessarily mean the system is more secure. It has one vulnerability less but let's not get overenthusiastic. I'm basically trying to point out that a single solution like that can do more evil than good if people will believe it's perfect. > > 3. What happens if the machine signing the blobs is compromised? > > > See above. But also, a compromised system wouldn't necessarily mean > the blobs would be compromised as well. In addition, ideally the > priv-key would be kept isolated to ensure a compromise would be > extremely difficult. In my opinion, if a toolchain is quietly compromised, everything built on the particular machine can be compromised. And signed. I doubt that someone will check bit-exact machine code of the toolchain and operating system before starting to sign packages. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, 17 Jun 2012 09:55:35 -0700 Greg KH wrote: > On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote: > > 2. What happens if, say, your bootloader is compromised? > > And how would this happen? Your bootloader would not run. Yes. I'm asking what happens next. Is there an easy way to replace it? Or is your computer bricked until you run some other bootloader to replace the compromised one? > > 3. What happens if the machine signing the blobs is compromised? > > So, who's watching the watchers, right? Come on, this is getting > looney. I'm just pointing out that this simply relies on trusting people. Much like not having those signatures. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sat, Jun 16, 2012 at 06:37:41PM -0500, Steev Klimaszewski wrote: > Just picking a random response to reply to. I'm not speaking > officially, however, I'm pretty sure we at Genesi aren't going to pay > Microsoft in order to boot our own boards. If you don't want your boards to be Windows 8 certified, then you are fine. Otherwise, you have to follow their guidelines, which I don't think requires paying them any money if you want to run Windows 8. Also, as these are "your own boards", you control the BIOS, so you don't even have to implement UEFI, or, if you do, you can control what keys are installed in the BIOS by default. So I don't understand the issue here, please explain. greg k-h
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny wrote: > On Sun, 17 Jun 2012 11:20:38 +0200 > Florian Philipp wrote: > > > Am 16.06.2012 19:51, schrieb Michał Górny: > > > On Fri, 15 Jun 2012 09:54:12 +0200 > > > Florian Philipp wrote: > > > > > >> Am 15.06.2012 06:50, schrieb Duncan: > > >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: > > >>> > > So, anyone been thinking about this? I have, and it's not > > pretty. > > > > Should I worry about this and how it affects Gentoo, or not worry > > about Gentoo right now and just focus on the other issues? > > > > Minor details like, "do we have a 'company' that can pay > > Microsoft to sign our bootloader?" is one aspect from the > > non-technical side that I've been wondering about. > > >>> > > >>> I've been following developments and wondering a bit about this > > >>> myself. > > >>> > > >>> I had concluded that at least for x86/amd64, where MS is mandating > > >>> a user controlled disable-signed-checking option, gentoo shouldn't > > >>> have a problem. Other than updating the handbook to accommodate > > >>> UEFI, presumably along with the grub2 stabilization, I believe > > >>> we're fine as if a user can't figure out how to disable that > > >>> option on their (x86/amd64) platform, they're hardly likely to be > > >>> a good match for gentoo in any case. > > >>> > > >> > > >> As a user, I'd still like to have the chance of using Secure Boot > > >> with Gentoo since it _really_ increases security. Even if it means > > >> I can no longer build my own kernel. > > > > > > It doesn't. It's just a very long wooden fence; you just didn't find > > > the hole yet. > > > > > > > Oh come on! That's FUD and you know it. If not, did you even look at > > the specs and working principle? > > Could you answer the following question: > (Sorry to jump in on this Florian) The real problem that surrounds this idea of security is that we need to make _a lot_ of assumptions about the code/programs we run. We _trust_ that the code we compile is as secure as possible and does not implement any "backdoors". If this is the case, then > 1. How does it increase security? > This removed a few vectors of attack and ensures your computer is only bootstrapped by and booted using software you think is safe. By using any software we don't write, we make a lot of assumptions. 2. What happens if, say, your bootloader is compromised? > Same thing that would happen if the bootloader was compromised today. We currently rely on trusting the maintainer, code review, community review, etc. Perhaps these efforts will need to be doubled now that any weak-link could compromise the system. > 3. What happens if the machine signing the blobs is compromised? > See above. But also, a compromised system wouldn't necessarily mean the blobs would be compromised as well. In addition, ideally the priv-key would be kept isolated to ensure a compromise would be extremely difficult. My understanding is that it's not the case that UEFI will lock down a system to prevent a compromise from occurring, it's the fact that it reduces the areas of attack and/or makes the attacks extremely difficult to accomplish. This just adds more protection in hardware for kernel-space that SELinux, apparmor, etc provide for userspace. - Matt
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote: > On Sun, 17 Jun 2012 11:20:38 +0200 > Florian Philipp wrote: > > > Am 16.06.2012 19:51, schrieb Michał Górny: > > > On Fri, 15 Jun 2012 09:54:12 +0200 > > > Florian Philipp wrote: > > > > > >> Am 15.06.2012 06:50, schrieb Duncan: > > >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: > > >>> > > So, anyone been thinking about this? I have, and it's not > > pretty. > > > > Should I worry about this and how it affects Gentoo, or not worry > > about Gentoo right now and just focus on the other issues? > > > > Minor details like, "do we have a 'company' that can pay > > Microsoft to sign our bootloader?" is one aspect from the > > non-technical side that I've been wondering about. > > >>> > > >>> I've been following developments and wondering a bit about this > > >>> myself. > > >>> > > >>> I had concluded that at least for x86/amd64, where MS is mandating > > >>> a user controlled disable-signed-checking option, gentoo shouldn't > > >>> have a problem. Other than updating the handbook to accommodate > > >>> UEFI, presumably along with the grub2 stabilization, I believe > > >>> we're fine as if a user can't figure out how to disable that > > >>> option on their (x86/amd64) platform, they're hardly likely to be > > >>> a good match for gentoo in any case. > > >>> > > >> > > >> As a user, I'd still like to have the chance of using Secure Boot > > >> with Gentoo since it _really_ increases security. Even if it means > > >> I can no longer build my own kernel. > > > > > > It doesn't. It's just a very long wooden fence; you just didn't find > > > the hole yet. > > > > > > > Oh come on! That's FUD and you know it. If not, did you even look at > > the specs and working principle? > > Could you answer the following question: > > 1. How does it increase security? Non-signed bootloaders and kernels will not run. > 2. What happens if, say, your bootloader is compromised? And how would this happen? Your bootloader would not run. > 3. What happens if the machine signing the blobs is compromised? So, who's watching the watchers, right? Come on, this is getting looney. greg k-h
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Sun, 17 Jun 2012 11:20:38 +0200 Florian Philipp wrote: > Am 16.06.2012 19:51, schrieb Michał Górny: > > On Fri, 15 Jun 2012 09:54:12 +0200 > > Florian Philipp wrote: > > > >> Am 15.06.2012 06:50, schrieb Duncan: > >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: > >>> > So, anyone been thinking about this? I have, and it's not > pretty. > > Should I worry about this and how it affects Gentoo, or not worry > about Gentoo right now and just focus on the other issues? > > Minor details like, "do we have a 'company' that can pay > Microsoft to sign our bootloader?" is one aspect from the > non-technical side that I've been wondering about. > >>> > >>> I've been following developments and wondering a bit about this > >>> myself. > >>> > >>> I had concluded that at least for x86/amd64, where MS is mandating > >>> a user controlled disable-signed-checking option, gentoo shouldn't > >>> have a problem. Other than updating the handbook to accommodate > >>> UEFI, presumably along with the grub2 stabilization, I believe > >>> we're fine as if a user can't figure out how to disable that > >>> option on their (x86/amd64) platform, they're hardly likely to be > >>> a good match for gentoo in any case. > >>> > >> > >> As a user, I'd still like to have the chance of using Secure Boot > >> with Gentoo since it _really_ increases security. Even if it means > >> I can no longer build my own kernel. > > > > It doesn't. It's just a very long wooden fence; you just didn't find > > the hole yet. > > > > Oh come on! That's FUD and you know it. If not, did you even look at > the specs and working principle? Could you answer the following question: 1. How does it increase security? 2. What happens if, say, your bootloader is compromised? 3. What happens if the machine signing the blobs is compromised? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 16.06.2012 19:51, schrieb Michał Górny: > On Fri, 15 Jun 2012 09:54:12 +0200 > Florian Philipp wrote: > >> Am 15.06.2012 06:50, schrieb Duncan: >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: >>> So, anyone been thinking about this? I have, and it's not pretty. Should I worry about this and how it affects Gentoo, or not worry about Gentoo right now and just focus on the other issues? Minor details like, "do we have a 'company' that can pay Microsoft to sign our bootloader?" is one aspect from the non-technical side that I've been wondering about. >>> >>> I've been following developments and wondering a bit about this >>> myself. >>> >>> I had concluded that at least for x86/amd64, where MS is mandating >>> a user controlled disable-signed-checking option, gentoo shouldn't >>> have a problem. Other than updating the handbook to accommodate >>> UEFI, presumably along with the grub2 stabilization, I believe >>> we're fine as if a user can't figure out how to disable that option >>> on their (x86/amd64) platform, they're hardly likely to be a good >>> match for gentoo in any case. >>> >> >> As a user, I'd still like to have the chance of using Secure Boot with >> Gentoo since it _really_ increases security. Even if it means I can no >> longer build my own kernel. > > It doesn't. It's just a very long wooden fence; you just didn't find > the hole yet. > Oh come on! That's FUD and you know it. If not, did you even look at the specs and working principle? Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: UEFI secure boot and Gentoo
Matthew Summers posted on Sat, 16 Jun 2012 18:52:31 -0500 as excerpted: > Pardon my ignorance, but will we be requires to sign the boot > loader/kernel on our install media for a Win8 machine to boot the iso? This was one of the issues covered early on. Unless it has changed, no. Booting external media (at least optical, not sure about USB-mass- storage, etc) bypasses the required signing, so that much, at least, should be safe. An initial proposal in fact would have required booting optical media in ordered to disable the sig-checks, etc, but AFAIK that was deemed too disruptive, particularly for netbooks and etc that don't normally have built-in optical media at all. It's worth noting that EFI can switch back to legacy mode for such things, and it's possible this exception is connected to el-torrito optical disk booting, tho I'm not sure on that. That's why I've specified optical, above. Direct-partitioned and bootable USB media may not be included. I'm sure GKH or others who have been following it closer can fill in the details. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Just picking a random response to reply to. I'm not speaking officially, however, I'm pretty sure we at Genesi aren't going to pay Microsoft in order to boot our own boards.
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Fri, 15 Jun 2012 09:54:12 +0200 Florian Philipp wrote: > Am 15.06.2012 06:50, schrieb Duncan: > > Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: > > > >> So, anyone been thinking about this? I have, and it's not pretty. > >> > >> Should I worry about this and how it affects Gentoo, or not worry > >> about Gentoo right now and just focus on the other issues? > >> > >> Minor details like, "do we have a 'company' that can pay Microsoft > >> to sign our bootloader?" is one aspect from the non-technical side > >> that I've been wondering about. > > > > I've been following developments and wondering a bit about this > > myself. > > > > I had concluded that at least for x86/amd64, where MS is mandating > > a user controlled disable-signed-checking option, gentoo shouldn't > > have a problem. Other than updating the handbook to accommodate > > UEFI, presumably along with the grub2 stabilization, I believe > > we're fine as if a user can't figure out how to disable that option > > on their (x86/amd64) platform, they're hardly likely to be a good > > match for gentoo in any case. > > > > As a user, I'd still like to have the chance of using Secure Boot with > Gentoo since it _really_ increases security. Even if it means I can no > longer build my own kernel. It doesn't. It's just a very long wooden fence; you just didn't find the hole yet. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 15.06.2012 14:28, schrieb Walter Dnes: > On Fri, Jun 15, 2012 at 09:54:12AM +0200, Florian Philipp wrote > >> I guess anti-trust is not an issue since MS is not even close to having >> a monopoly in ARM. > > Will you be able to get an ARM machine without their UEFI? If MS > ever gets huge in the ARM arena, and 95% of ARM cpus go into Windows > machines, how many companies will make cpus for the remaining 5%. > Remember how MS strongarmed OEMs into a "Windows tax"? > When MS gets a strong hold in ARM, they will have to face the same antitrust measures they face on x86 and their policy will likely have to change. I don't say its a nice outlook. The whole antitrust system is reactive and takes years to have any effect. But until then (if it ever happens)? Support other big players in ARM, don't buy Nokia/Windows phones, hope for the best. The usual ... Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 09:54:12AM +0200, Florian Philipp wrote > I guess anti-trust is not an issue since MS is not even close to having > a monopoly in ARM. Will you be able to get an ARM machine without their UEFI? If MS ever gets huge in the ARM arena, and 95% of ARM cpus go into Windows machines, how many companies will make cpus for the remaining 5%. Remember how MS strongarmed OEMs into a "Windows tax"? -- Walter Dnes
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
Am 15.06.2012 06:50, schrieb Duncan: > Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: > >> So, anyone been thinking about this? I have, and it's not pretty. >> >> Should I worry about this and how it affects Gentoo, or not worry about >> Gentoo right now and just focus on the other issues? >> >> Minor details like, "do we have a 'company' that can pay Microsoft to >> sign our bootloader?" is one aspect from the non-technical side that >> I've been wondering about. > > I've been following developments and wondering a bit about this myself. > > I had concluded that at least for x86/amd64, where MS is mandating a user > controlled disable-signed-checking option, gentoo shouldn't have a > problem. Other than updating the handbook to accommodate UEFI, > presumably along with the grub2 stabilization, I believe we're fine as if > a user can't figure out how to disable that option on their (x86/amd64) > platform, they're hardly likely to be a good match for gentoo in any case. > As a user, I'd still like to have the chance of using Secure Boot with Gentoo since it _really_ increases security. Even if it means I can no longer build my own kernel. > ARM and etc could be more problematic since MS is mandating no-unlock > there, last I read. I have no clue how they can get away with that anti- > trust-wise, but anyway... But I honestly don't know enough about other > than x86/amd64 platforms to worry about it, personally. > I guess anti-trust is not an issue since MS is not even close to having a monopoly in ARM. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 12:50 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: > > > So, anyone been thinking about this? I have, and it's not pretty. > > > > Should I worry about this and how it affects Gentoo, or not worry about > > Gentoo right now and just focus on the other issues? > > > > Minor details like, "do we have a 'company' that can pay Microsoft to > > sign our bootloader?" is one aspect from the non-technical side that > > I've been wondering about. > > I've been following developments and wondering a bit about this myself. > > I had concluded that at least for x86/amd64, where MS is mandating a user > controlled disable-signed-checking option, gentoo shouldn't have a > problem. Other than updating the handbook to accommodate UEFI, > presumably along with the grub2 stabilization, I believe we're fine as if > a user can't figure out how to disable that option on their (x86/amd64) > platform, they're hardly likely to be a good match for gentoo in any case. > > ARM and etc could be more problematic since MS is mandating no-unlock > there, last I read. I have no clue how they can get away with that anti- > trust-wise, but anyway... But I honestly don't know enough about other > than x86/amd64 platforms to worry about it, personally. > For the short term, we don't have many options beside either adding to the documentation that the User needs to disable UEFI or wipe the current valid keys and adding their own (Devs may need to make sure there's a way to do this on the livecd). Of course there's the third option of everyone purchasing a key from Verisign but As for non-x86 systems, Gentoo is in between a rock and a hard place. I hope there will be a similar mechanism for the user to implement their own valid key chain and remove Microsofts, but who knows. The the devs and we need to decide on a uniform way of handling this situation. - Matt
[gentoo-dev] Re: UEFI secure boot and Gentoo
Arun Raghavan posted on Fri, 15 Jun 2012 10:15:28 +0530 as excerpted: > I guess we're in an especially bad position since everybody builds their > own bootloader. Is there /any/ viable solution that allows people to > continue doing this short of distributing a first-stage bootloader blob? As I said in my first reply, for x86/amd64 at least, MS is mandating a user-unlock option. That would leave the bootloader fully unsigned, but it would let users keep building their own. But for arm, last I read MS is mandating no-user-unlock. There, a signed blob first-stage bootloader is likely to be mandatory, tho in reality that platform has always lacked the user-end base standard support and flexibility of x86, so it's not like they're losing it. But if the entire market moves toward arm as some are predicting... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: UEFI secure boot and Gentoo
Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted: > So, anyone been thinking about this? I have, and it's not pretty. > > Should I worry about this and how it affects Gentoo, or not worry about > Gentoo right now and just focus on the other issues? > > Minor details like, "do we have a 'company' that can pay Microsoft to > sign our bootloader?" is one aspect from the non-technical side that > I've been wondering about. I've been following developments and wondering a bit about this myself. I had concluded that at least for x86/amd64, where MS is mandating a user controlled disable-signed-checking option, gentoo shouldn't have a problem. Other than updating the handbook to accommodate UEFI, presumably along with the grub2 stabilization, I believe we're fine as if a user can't figure out how to disable that option on their (x86/amd64) platform, they're hardly likely to be a good match for gentoo in any case. ARM and etc could be more problematic since MS is mandating no-unlock there, last I read. I have no clue how they can get away with that anti- trust-wise, but anyway... But I honestly don't know enough about other than x86/amd64 platforms to worry about it, personally. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
