Re: [gentoo-dev] UEFI secure boot and Gentoo
On Sun, Jun 17, 2012 at 8:03 PM, Greg KH wrote: > Huh? No, why would a user need to resign the UEFI drivers? Those > "live" in the BIOS and are only used to get the machine up and running > in UEFI space, before UEFI hands the control off to the bootloader it > has verified is signed with a correct key. Is that always the case? E.g., kernel's efifb module uses the EFI console driver, similarly to legacy BIOS's VESA interface. It is possible that in the future more OS-usable EFI drivers will become commonplace, especially for non-performance-critical periphery interaction (sensors, etc.). Architecture-independent EFI bytecode drivers apparently don't have OS interface now, but this could change as well. >> If the user does not perform this procedure (due to its >> complexity and/or lack of tools automating the process), is it >> possible for an externally connected device to compromise the system >> by supplying a Microsoft-signed blob directly to the UEFI firmware, >> circumventing the (Linux) OS? > > Again, what? Please explain. I am thinking about a possibility where a “rogue” device can upload its driver directly to the UEFI firmware. I don't see something like that in the UEFI spec, but perhaps the firmware can support such behavior outside the spec. E.g., many 3G network tokens support presenting themselves as network devices or as storage media on the USB bus (sys-apps/usb_modeswitch deals with that). The reason they do that is for the OS to install the network driver from the storage media “representation”. Now, imagine that the OS defers handling of unfamiliar network devices to the UEFI network driver (as it might do with unfamiliar video cards and UEFI GOP). It makes sense that UEFI firmware vendors would support a similar mechanism of loading (possibly EBC) UEFI drivers from the network device. Why not — the drivers will be signed, and UEFI can verify the signatures. So it seems to me that UEFI, because of its complexity and multitude of features, may provide an OS-circumventing attack vector, which can only be dealt with by revoking (probably Microsoft) keys in UEFI firmware, and re-signing only the necessary drivers with a custom key. Compromising major player's certificates is a real possibility — e.g., see http://www.pcpro.co.uk/news/security/375169/could-us-cyberspies-have-moles-inside-microsoft. > What API? The signing tool is public, and no, it doesn't add keys, > that's up to the BIOS to do, not the userspace tool. So the re-signing mentioned above must be done in a tedious manual process? Or can some automatic tool be developed (not necessary userspace, it can be an EFI app)? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Sat, Jun 16, 2012 at 12:22:24PM +0300, Maxim Kammerer wrote: > On Fri, Jun 15, 2012 at 3:01 PM, Rich Freeman wrote: > > I think that anybody that really cares about security should be > > running in custom mode anyway, and should just re-sign anything they > > want to run. Custom mode lets you clear every single key in the > > system from the vendor on down, and gives you the ability to ensure > > the system only boots stuff you want it to. > > I have several questions, that hopefully someone familiar with UEFI > Secure Boot is able to answer. If I understand UEFI correctly, the > user will need to not just re-sign bootloaders, but also the > OS-neutral drivers (e.g., UEFI GOP), which are hardware-specific, and > will be probably signed with Microsoft keys, since the hardware vendor > would otherwise need to implement expensive key security measures — is > that correct? Huh? No, why would a user need to resign the UEFI drivers? Those "live" in the BIOS and are only used to get the machine up and running in UEFI space, before UEFI hands the control off to the bootloader it has verified is signed with a correct key. > If the user does not perform this procedure (due to its > complexity and/or lack of tools automating the process), is it > possible for an externally connected device to compromise the system > by supplying a Microsoft-signed blob directly to the UEFI firmware, > circumventing the (Linux) OS? Again, what? Please explain. > Is it possible to develop an automatic > re-signing tool — i.e., does the API support all needed features > (listing / extracting drivers, revoking keys, adding keys, etc.)? What API? The signing tool is public, and no, it doesn't add keys, that's up to the BIOS to do, not the userspace tool. confused, greg k-h
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Thu, Jun 14, 2012 at 11:28 PM, Greg KH wrote: > > 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. > > thanks, > > greg k-h > 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? -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 3:01 PM, Rich Freeman wrote: > I think that anybody that really cares about security should be > running in custom mode anyway, and should just re-sign anything they > want to run. Custom mode lets you clear every single key in the > system from the vendor on down, and gives you the ability to ensure > the system only boots stuff you want it to. I have several questions, that hopefully someone familiar with UEFI Secure Boot is able to answer. If I understand UEFI correctly, the user will need to not just re-sign bootloaders, but also the OS-neutral drivers (e.g., UEFI GOP), which are hardware-specific, and will be probably signed with Microsoft keys, since the hardware vendor would otherwise need to implement expensive key security measures — is that correct? If the user does not perform this procedure (due to its complexity and/or lack of tools automating the process), is it possible for an externally connected device to compromise the system by supplying a Microsoft-signed blob directly to the UEFI firmware, circumventing the (Linux) OS? Is it possible to develop an automatic re-signing tool — i.e., does the API support all needed features (listing / extracting drivers, revoking keys, adding keys, etc.)? -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] UEFI secure boot and Gentoo
Am 16.06.2012 01:59, schrieb Greg KH: > On Fri, Jun 15, 2012 at 09:49:01AM +0200, Florian Philipp wrote: >> Am 15.06.2012 09:26, schrieb Michał Górny: >>> On Thu, 14 Jun 2012 21:56:04 -0700 Greg KH wrote: On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: > On 15 June 2012 09:58, Greg KH wrote: >> 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? > > I think it at least makes sense to talk about it, and work out what > we can and cannot do. > > 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? Distributing a first-stage bootloader blob, that is signed by Microsoft, or someone, seems to be the only way to easily handle this. >>> >>> Maybe we could get one such a blob for all distros/systems? >>> >> >> I guess nothing prevents you from re-distributing Fedora's blob. > > Fedora's blob will not boot your unsigned-with-fedoras-key kernel, so > redistributing it will not help anyone :( > I meant along with Fedora's kernel, signed binary modules and so forth. The whole kernel space. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, 15 Jun 2012 16:56:52 -0700 Greg KH wrote: > On Fri, Jun 15, 2012 at 06:57:06AM +0200, Chí-Thanh Christopher > Nguyễn wrote: > > If you have influence on UEFI secure boot spec, you could suggest > > that they mandate a UI which lists all boot images known to the EFI > > boot manager, and the user can easily whitelist both individual > > loaders and the keys used to sign them. > > That has already been attempted, and it failed, so it will not happen, > sorry. We can still have some hope that EU is going to bounce this for a while like they did with Internet Explorer. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 08:41:47PM -0400, Rich Freeman wrote: > On Fri, Jun 15, 2012 at 7:55 PM, Greg KH wrote: > > On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote: > > The whole chain-of-trust is an interesting issue as the UEFI spec does > > not require it at all, and some people on the UEFI committee have told > > me that it is not required either. But, others have. Getting to the > > root of this problem is something I'm trying to do, as it's a very > > important one for anyone who is going to be trusting, and providing, a > > key in the BIOS. > > It sounds like the UEFI committee isn't really the problem here. You > can have a UEFI firmware as long as it follows the spec. However, you > won't get the Windows logo certification if you don't follow the > Windows rules. That is exactly the case. > I would think they'd basically want a chain of trust for anything that > loads into kernel space. Otherwise all a malware author has to do is > ship a signed linux kernel, have it boot a bash script that loads > their malware via an unsigned kernel module, and then at that point > they just intercept whatever they want to and then boot Windows, > discarding the rest of the linux kernel. Yes, that is the problem we are facing. > However, even the MS requirements say that an OEM can have other keys > as well, and nothing says that all of them need to be secure (other > than the root key). If I published a keypair on the internet and > persuaded OEMs to include it as trusted, then in theory that would > pass the MS requirements as they are currently written, and would > render secure boot meaningless. The liability requirements for an OEM to accept a key into their BIOS, that is something other than Microsoft's key (if there is even the room, some bioses will not have extra room for lots of keys), is beyond anything that any Linux company can afford, or is willing to accept. greg k-h
Re: [gentoo-dev] UEFI secure boot and Gentoo
120615 Greg KH wrote: > On Fri, Jun 15, 2012 at 01:48:05AM -0400, Philip Webb wrote: >> Does this affect those of us who build our own machines ? > Yes, it will be on your new motherboard in a matter of months. I am going to build a new machine some time in the next 12 mth , but it looks as if all I will have to do is reset the BIOS , which I'm likely to have to do for other features in any case. >> Is there likely to be any Gentoo user >> who is reluctant to change the default BIOS setting ? > Probably lots. That surprises me, but we'll find out. >> How can UEFI be required for Arm without running into anti-trust ? > Different countries have different rules here. Discussion + news items in the press do suggest that it's not anti-trust as long as it's not benefitting 1 company. Anyway, I'm not likely to be using ARM, let alone jailbreaking it. >> How far is this basically a problem for those in the USA, >> the rest of us having a different attitude to security issues ? > Everyone in all countries are going to have to deal with this, > as all motherboard manufacturers are going to be supporting this > by the end of 2012 at the latest, due to the Windows 8 requirements. As with other similar issues in the past, we can expect the EU antitrust people to take a close look at it & they may start demanding that computers are easily unlockable, if not actually required to be sold with UEFI disabled by default. Despite current scare stories out of London & New York, the EU is by no means finished as a political entity & no-one in USA should assume the EU will follow their lead or even that Canada will, despite our current Conservative government. I see a need for careful thought at Gentoo, but no need for panic. Thanks for your horse's mouth (smile). -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 7:55 PM, Greg KH wrote: > On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote: > The whole chain-of-trust is an interesting issue as the UEFI spec does > not require it at all, and some people on the UEFI committee have told > me that it is not required either. But, others have. Getting to the > root of this problem is something I'm trying to do, as it's a very > important one for anyone who is going to be trusting, and providing, a > key in the BIOS. It sounds like the UEFI committee isn't really the problem here. You can have a UEFI firmware as long as it follows the spec. However, you won't get the Windows logo certification if you don't follow the Windows rules. I would think they'd basically want a chain of trust for anything that loads into kernel space. Otherwise all a malware author has to do is ship a signed linux kernel, have it boot a bash script that loads their malware via an unsigned kernel module, and then at that point they just intercept whatever they want to and then boot Windows, discarding the rest of the linux kernel. However, even the MS requirements say that an OEM can have other keys as well, and nothing says that all of them need to be secure (other than the root key). If I published a keypair on the internet and persuaded OEMs to include it as trusted, then in theory that would pass the MS requirements as they are currently written, and would render secure boot meaningless. Rich
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 09:26:07AM +0200, Michał Górny wrote: > On Thu, 14 Jun 2012 21:56:04 -0700 > Greg KH wrote: > > > On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: > > > On 15 June 2012 09:58, Greg KH wrote: > > > > 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? > > > > > > I think it at least makes sense to talk about it, and work out what > > > we can and cannot do. > > > > > > 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? > > > > Distributing a first-stage bootloader blob, that is signed by > > Microsoft, or someone, seems to be the only way to easily handle this. > > Maybe we could get one such a blob for all distros/systems? > > Also, does this signature system have any restrictions on what is > signed and what is not? In other words, will they actually sign a blob > saying 'work-around signatures' on the top? It is uncertian at the moment what the requirements are, I'm trying to nail this down. But, in order to protect all other companies, I imagine they are going to be pretty restrictive, otherwise it really makes no sense at all to have this in the first place. greg k-h
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 01:03:24PM +0800, Ben de Groot wrote: > On 15 June 2012 12:45, Arun Raghavan wrote: > > On 15 June 2012 09:58, Greg KH wrote: > >> So, anyone been thinking about this? I have, and it's not pretty. > >> > >> 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. > > > > Sounds like something the Gentoo Foundation could do. > > I'm certainly not the only one who would be averse to paying Microsoft > any ransom money. Sorry, it's really Verisign, although I imagine you still feel the same :)
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 01:48:05AM -0400, Philip Webb wrote: > 120614 Greg KH wrote: > > 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. > > I did a lot of UEFI secure boot work in the past at SUSE > > and should be soon a member of the UEFI "organization" > > through my work at the Linux Foundation, so I do have a basic grasp > > of the issues involved and have a chance to get changes made, > > if needed and possible, to the spec itself. > > Does this affect those of us who build our own machines ? Yes, it will be on your new motherboard in a matter of months. > Is there likely to be any Gentoo user > who is reluctant to change the default BIOS setting ? Probably lots. > How can UEFI be required for Arm without running into anti-trust ? Different countries have different rules here. > How far is this basically a problem for those in the USA, > the rest of us having a different attitude to security issues ? Everyone in all countries are going to have to deal with this, as all motherboard manufacturers are going to be supporting this by the end of this year at the latest, due to the Windows 8 requirements. greg k-h
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 04:35:28PM -0500, Matthew Thode wrote: > One of these days I'd like to pick your brain about some hardened UEFI > interactions I've seen (with pipacs watching). Sure, be glad to talk about this anytime.
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 09:49:01AM +0200, Florian Philipp wrote: > Am 15.06.2012 09:26, schrieb Michał Górny: > > On Thu, 14 Jun 2012 21:56:04 -0700 Greg KH wrote: > >> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: > >>> On 15 June 2012 09:58, Greg KH wrote: > 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? > >>> > >>> I think it at least makes sense to talk about it, and work out what > >>> we can and cannot do. > >>> > >>> 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? > >> > >> Distributing a first-stage bootloader blob, that is signed by > >> Microsoft, or someone, seems to be the only way to easily handle this. > > > > Maybe we could get one such a blob for all distros/systems? > > > > I guess nothing prevents you from re-distributing Fedora's blob. Fedora's blob will not boot your unsigned-with-fedoras-key kernel, so redistributing it will not help anyone :( greg k-h
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 06:57:06AM +0200, Chí-Thanh Christopher Nguyễn wrote: > If you have influence on UEFI secure boot spec, you could suggest that > they mandate a UI which lists all boot images known to the EFI boot > manager, and the user can easily whitelist both individual loaders and > the keys used to sign them. That has already been attempted, and it failed, so it will not happen, sorry. greg k-h
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote: > On Fri, Jun 15, 2012 at 12:28 AM, Greg KH wrote: > > 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. > > So, there are 22 posts already, so I'm going to try to cover a bunch > of topics in one post. I've been thinking about this a fair bit. > > 1. Speaking as an individual trustee... The Gentoo Foundation > legally speaks for Gentoo, can sign contracts, and can write checks. > I don't really forsee any legal issues should we decide we want to > pursue any kinds of relationships with MS or other entities associated > with UEFI. Obviously any decision to actually pursue this would not > be taken lightly. Great to know that this could work, if needed. > 2. From what I've heard the cost of getting a key that would be > recognized by UEFI firmware is as low as a $99 one-time payment, and > we pay many times that for stuff like trademark registration, > corporate filing fees, not to mention hardware for infrastructure. > Cost is likely a non-issue. Yes, it's cheap. > 3. Freedom IS a big issue - my sense is that getting support from the > powers that be for UEFI comes with a lot of strings. If we had a key > the easiest solution would be to just write a signed GRUB stage1 that > works exactly like the one we're all using, and it would load whatever > you want, linux or windows or Stuxnet or otherwise. Once Malware > writers start embedding our bootloader in their stuff I assume that > the people issuing the keys will have the ability to revoke it (at > least for new hardware). Yes, we need to provide some way to "secure" our key, which might prove impossible and foolish for Gentoo to even attempt, as it really wouldn't work out for us. > 4. Fedora is getting around #3 by making the whole thing a big > trusted infrastructure - signature chains for all the kernel-space > code. That meshes well with their whole /usr move initiative - you > just have this big blog of stuff that you trust and never touch, and > you can be sure you're running genuine RedHat goodness, just like all > those iPhone users out there. :) The whole chain-of-trust is an interesting issue as the UEFI spec does not require it at all, and some people on the UEFI committee have told me that it is not required either. But, others have. Getting to the root of this problem is something I'm trying to do, as it's a very important one for anyone who is going to be trusting, and providing, a key in the BIOS. > 5. If somebody (perhaps under the umbrella of hardened) wanted to > create a Gentoo project around a fully trusted Gentoo I'd be > completely supportive of that. It would take work. In the spirit of > Gentoo we should allow anybody to build their own signed with their > own key, and perhaps we might have an official Gentoo-certified one > that we would sign and the Foundation would obtain the necessary UEFI > keys. However, that should be viewed as more of a service, and not a > core offering - Gentoo will never depend on a piece of non-free > software or metadata (and I'd probably lump a signing key into that > category). The same tools (minus the private keys) used to generate > any secure offering made by Gentoo should be available for users to > use and sign their own systems. That would mean we would be in the business of creating binary packages, which is a big change from what we have been doing all of these years, and not to be taken lightly. > 6. At least on x86 users can either disable secure boot, or load > their own signing keys. We should try to support both. Yes. > While the full secure infrastructure of #5 will undoubtedly be a > significant effort we could at least have the handbook have a section > on how to sign your grub when building it and install it in a way that > it can be used to boot (installing the keys themselves might be > firmware-dependent, but to the extent that standards exist we can be > helpful). Yes. > > 7. In general anybody who would be a happy Gentoo user should have no > issues with signing their own bootloader, or disabling secure boot. We have not seen how most BIOSes will allow this to happen, so I can't agree with this statement just yet. > 8. I think the bigger issue is with ARM, and I'm not personally clear > on what the exact policy is there. That really strikes me as > antitrust, but MS might argue that on ARM they have no monopoly > (instead we have a bunch of different vendors who almost universally > lock down their hardware). I can't really see how any solution that > didn't give the end-user the ability to run arbitrary code on their > machine could be called "Gentoo" so our ability to distribute signed > bootloaders there is going
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/14/2012 11:45 PM, Greg KH wrote: > On Thu, Jun 14, 2012 at 09:28:10PM -0700, Greg KH wrote: >> 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. > > Oh, and for those that don't know, I did a lot of UEFI secure boot work > in the past at SUSE, and should be soon a member of the UEFI > "organization" through my work at the Linux Foundation, so I do have a > basic grasp of the issues involved, and have a chance to get changes > made, if needed, and possible, to the spec itself. > > greg k-h > One of these days I'd like to pick your brain about some hardened UEFI interactions I've seen (with pipacs watching). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/15/2012 12:24 AM, Arun Raghavan wrote: > On 15 June 2012 10:26, Greg KH wrote: >> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: >>> On 15 June 2012 09:58, Greg KH wrote: 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? >>> >>> I think it at least makes sense to talk about it, and work out what we >>> can and cannot do. >>> >>> 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? >> >> Distributing a first-stage bootloader blob, that is signed by Microsoft, >> or someone, seems to be the only way to easily handle this. >> >> Although all BIOSes will have the option to turn secure boot off, I >> think it is something that we might not want to require for Gentoo to >> work properly on those machines. >> >> Also, some people might really want to sign their own bootloader and >> kernel, and kernel modules (myself included), so just getting that basic >> infrastructure in place is going to take some work, no matter who ends >> up signing the first-stage bootloader blob. > > I hadn't thought of that. I imagine the hardened team might be > interested in making such infrastructure easily available as well. > >> Oh, and on the first-stage bootloader front, I already know of 2 simple, >> and open source, examples that will work for Linux, so getting something >> like that signed might not be very tough. It's the "where does the >> chain-of-trust stop" question that gets tricky... > > For validating the chain of trust, it might be useful to make it > possible for anyone to generate the same bootloader and verify the > hashes themselves. For the truly paranoid maybe a signed stage3 + > portage snapshot to generate the bootloader image from scratch. > 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. >>> >>> Sounds like something the Gentoo Foundation could do. >> >> Can they do that? I haven't been paying attention to if we are really a >> legal entity still or not, sorry. > > I believe so, but quantumsummers is likely the best person to confirm. > I've already taken a look at some of this, I think our best bet is to figure out how to use efi_stub and simply sign the kernel itself (since it can run directly from uefi now). -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/15/2012 06:14 AM, Rich Freeman wrote: 8. I think the bigger issue is with ARM, and I'm not personally clear on what the exact policy is there. That really strikes me as antitrust, but MS might argue that on ARM they have no monopoly (instead we have a bunch of different vendors who almost universally lock down their hardware). This requirement by M$ is applied to hardware that wants the "Certified for Windows 8" logo. If the OEMs don't care about windows 8 certification, they can provide for UEIF secure boot disabling. Since it is a "voluntary" acceptance in return for granting a consumer-fooling certification, they get away with an anti-competetive practice. They want to keep android off hardware used for Windows 8. Always follow the money. -- G.Wolfe Woodbury
Re: [gentoo-dev] UEFI secure boot and Gentoo
Am 15.06.2012 14:01, schrieb Rich Freeman: > On Fri, Jun 15, 2012 at 7:32 AM, Walter Dnes wrote: >> Question... how would "blacklisting" work on linux machines? Let's >> say Joe Blow gets a signing key and then passes it around. I can see >> that if you want to build an executable (*.exe) to run under Windows, >> you'll run into problems if the monthly MS Windows Update kills that >> specific key. > > I took the time to read the MS Hardware Certification guide. I > haven't read the full UEFI spec though it is referenced to it. It > sounds like UEFI has a provision for revocation, and that includes an > area of flash to store revoked keys. So, if you booted the device on > Windows, then Windows could download a list of keys MS doesn't like, > and then since Windows is trusted by the firmware it could add those > keys to the flash. Then on a reboot the firmware would no longer boot > those keys in secure mode. > > So, the revocation is non-volatile, and doesn't require a firmware > update. Besides, even if there was no update mechanism, it wouldn't help us. Even if our key was only blacklisted in the next generation of mainboards, what would we have gained? We cannot purposefully break the system every time a new mainboard is released. > Of course, if you never run Windows on the device then it > probably won't get the update. From skimming the UEFI specs it sounds like there are similar tools for Linux under development. > It wasn't 100% clear, but it sounds > like a full factory reset of the firmware might clear these revoked > keys out (it definitely is supposed to clear out any custom keys you > load). > > After reading up it seems to me that the best bet for somebody who > wants free as in freedom is to just run in custom mode and load their > own keys. > > The MS document leaves a lot of policy questions unanswered though. > The vendor has to trust the MS key, and has to secure their root keys. > However, they can trust any number of keys, and nothing is said about > those keys having to be secure. It seems like that is a loophole that > would be rapidly closed in practice if a vendor got "out of line." > > For ARM users are up the creek unless they can get the vendor to > include their keys, or get a signature from somebody whose keys are > included. ARM lacks the ability to use custom mode, which means you > can't load your own keys, and it can't disable secure boot. > > Then again, all of this is only as good as the implementation. My > current Android phone used just about all the tricks in the spec > (flash is locked by bootloader, no downgrading, and so on). However, > in the case of my phone messing with the power supply can reset the > flash controller before it resets the CPU, unlocking it and allowing a > rooted device to flash the bootloader. However, the UEFI specs > themselves seem secure, and you can't count on every piece of hardware > having an exploit. > > I think that anybody that really cares about security should be > running in custom mode anyway, and should just re-sign anything they > want to run. Custom mode lets you clear every single key in the > system from the vendor on down, and gives you the ability to ensure > the system only boots stuff you want it to. The MS spec does require > a full factory reset to restore the original keys, though if you're > using secure boot and TPM you could ensure that your hard drive > becomes unreadable if this is done (unless the TPM has some backdoor > and your vendor is complicit in accessing it). I don't have a problem > with secure boot, and obviously to use it any pre-loaded OS has to > have pre-loaded keys. What I don't like is the way certain companies > are getting privileged in the process. If a full factory reset > unlocked the machine, letting the first CD you boot from restore that > OS vendor's keys or whatever, then then that would be more neutral. > The whole bit about not allowing users to load their keys on ARM is > obviously objectionable - I'm fine with ensuring security by making > the user go into the pre-boot firmware, but the computer owner should > have the final say. > Yeah, the ARM policy is a pretty obvious "don't root the phone" attempt. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 8:22 AM, Luca Barbato wrote: > If we want to try to get serious on 5, we could try to gather the > hardened/security people across distributions and setup the whole chain > to be parallel and cut deals with OEM to store this trust-chain keys > along with MS. Perhaps. Since we're only talking about the kernel really and that doesn't vary as much across distros, we might even be able to get momentum for it. You could create a standard "secure kernel" - probably as a patch set initially but perhaps merged into mainline with a config option that turns on key verification for loading modules. Anybody could use that to secure their own systems by using their own key in the configuration. The central body could prepare and sign binaries for individual distros. A distro would supply a kernel config file and patch set and identifier for the upstream kernel to build against. The central body would audit the patches and config for security, build the kernel, and sign it, assessing a fee perhaps (likely cheap for config-only, and expensive for extensive patches). The costs need not be all that high - if you assume that vanilla linux with the config option turned on is good enough then you only have to check that the option is set, blacklist "bad" settings, and verify patches. They could revoke certs when security issues are found, by keeping a history of what configs/versions got signed. Users could load the signing key of this body into their custom settings, or OEMs could be persuaded to include it. The latter would never be 100% effective unless a court ordered it. Rich
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 8:18 AM, Luca Barbato wrote: > On 06/15/2012 06:57 AM, Chí-Thanh Christopher Nguyễn wrote: >> If you have influence on UEFI secure boot spec, you could suggest that >> they mandate a UI which lists all boot images known to the EFI boot >> manager, and the user can easily whitelist both individual loaders and >> the keys used to sign them. >> > > That would be a good compromise. > Agreed, though MS is likely to be sensitive about how this is done. One of their requirements: System.Fundamentals.Firmware.UEFISecureBoot / 14: Mandatory. No in-line mechanism is provided whereby a user can bypass Secure Boot failures and boot anyway Signature verification override during boot when Secure Boot is enabled is not allowed. A physically present user override is not permitted for UEFI images that fail signature verification during boot. If a user wants to boot an image that does not pass signature verification, they must explicitly disable Secure Boot on the target system. Sounds like they want to make getting around signature issues a fairly technical exercise. This of course raises the barrier to loading another OS, though to be fair the "Stuxnet wants to access your boot sector - hit OK to allow or Cancel to not display the cute video your friend sent you" options that are typical these days hasn't really been very effective in keeping out malware. Rich
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/15/2012 12:14 PM, Rich Freeman wrote: > 5. If somebody (perhaps under the umbrella of hardened) wanted to > create a Gentoo project around a fully trusted Gentoo I'd be > completely supportive of that. It would take work. In the spirit of > Gentoo we should allow anybody to build their own signed with their > own key, and perhaps we might have an official Gentoo-certified one > that we would sign and the Foundation would obtain the necessary UEFI > keys. However, that should be viewed as more of a service, and not a > core offering - Gentoo will never depend on a piece of non-free > software or metadata (and I'd probably lump a signing key into that > category). The same tools (minus the private keys) used to generate > any secure offering made by Gentoo should be available for users to > use and sign their own systems. If we want to try to get serious on 5, we could try to gather the hardened/security people across distributions and setup the whole chain to be parallel and cut deals with OEM to store this trust-chain keys along with MS. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/15/2012 06:57 AM, Chí-Thanh Christopher Nguyễn wrote: > Greg KH schrieb: >> 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. > > For the current crop of hardware, it is probably sufficient to add a > paragraph to the handbook which tells the user to disable secure boot. > > Getting users' self-compiled boot loaders signed with a Gentoo key is > probably infeasible. > > If you have influence on UEFI secure boot spec, you could suggest that > they mandate a UI which lists all boot images known to the EFI boot > manager, and the user can easily whitelist both individual loaders and > the keys used to sign them. > That would be a good compromise. -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 7:32 AM, Walter Dnes wrote: > Question... how would "blacklisting" work on linux machines? Let's > say Joe Blow gets a signing key and then passes it around. I can see > that if you want to build an executable (*.exe) to run under Windows, > you'll run into problems if the monthly MS Windows Update kills that > specific key. I took the time to read the MS Hardware Certification guide. I haven't read the full UEFI spec though it is referenced to it. It sounds like UEFI has a provision for revocation, and that includes an area of flash to store revoked keys. So, if you booted the device on Windows, then Windows could download a list of keys MS doesn't like, and then since Windows is trusted by the firmware it could add those keys to the flash. Then on a reboot the firmware would no longer boot those keys in secure mode. So, the revocation is non-volatile, and doesn't require a firmware update. Of course, if you never run Windows on the device then it probably won't get the update. It wasn't 100% clear, but it sounds like a full factory reset of the firmware might clear these revoked keys out (it definitely is supposed to clear out any custom keys you load). After reading up it seems to me that the best bet for somebody who wants free as in freedom is to just run in custom mode and load their own keys. The MS document leaves a lot of policy questions unanswered though. The vendor has to trust the MS key, and has to secure their root keys. However, they can trust any number of keys, and nothing is said about those keys having to be secure. It seems like that is a loophole that would be rapidly closed in practice if a vendor got "out of line." For ARM users are up the creek unless they can get the vendor to include their keys, or get a signature from somebody whose keys are included. ARM lacks the ability to use custom mode, which means you can't load your own keys, and it can't disable secure boot. Then again, all of this is only as good as the implementation. My current Android phone used just about all the tricks in the spec (flash is locked by bootloader, no downgrading, and so on). However, in the case of my phone messing with the power supply can reset the flash controller before it resets the CPU, unlocking it and allowing a rooted device to flash the bootloader. However, the UEFI specs themselves seem secure, and you can't count on every piece of hardware having an exploit. I think that anybody that really cares about security should be running in custom mode anyway, and should just re-sign anything they want to run. Custom mode lets you clear every single key in the system from the vendor on down, and gives you the ability to ensure the system only boots stuff you want it to. The MS spec does require a full factory reset to restore the original keys, though if you're using secure boot and TPM you could ensure that your hard drive becomes unreadable if this is done (unless the TPM has some backdoor and your vendor is complicit in accessing it). I don't have a problem with secure boot, and obviously to use it any pre-loaded OS has to have pre-loaded keys. What I don't like is the way certain companies are getting privileged in the process. If a full factory reset unlocked the machine, letting the first CD you boot from restore that OS vendor's keys or whatever, then then that would be more neutral. The whole bit about not allowing users to load their keys on ARM is obviously objectionable - I'm fine with ensuring security by making the user go into the pre-boot firmware, but the computer owner should have the final say. Rich
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 10:37:02AM +0200, Florian Philipp wrote > Besides, it wouldn't work long. They can blacklist keys. Question... how would "blacklisting" work on linux machines? Let's say Joe Blow gets a signing key and then passes it around. I can see that if you want to build an executable (*.exe) to run under Windows, you'll run into problems if the monthly MS Windows Update kills that specific key. How could MS do anything to linux users who used the key to get their machine running? All I can think of is that the blacklisted keys would be added to some encrypted table in the UEFI in future versions of the UEFI/BIOS. Oh yeah, remember to *NOT* do unnecessary firmware updates to your UEFI/BIOS. As for a signed 1st-stage bootloader, is it just me, or is nobody else concerned/paranoid about MS sticking their binary code on my machine? We used to laugh at Sony rootkits, but that's what we could be looking at here. -- Walter Dnes
Re: [gentoo-dev] UEFI secure boot and Gentoo
Am 15.06.2012 12:14, schrieb Rich Freeman: [...] +1 for your assessment so far. > > I'd be personally interested in pointers to info on what the "powers > that be" do and don't allow with UEFI. I've seen lots of > sky-is-falling blog entries and discussion but little in the way of > specs, and more importantly, policies. > > Rich > Specs and user manuals can be found here: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK_II_User_Documentation More detailed specs can be found on http://www.uefi.org The UEFI Specification v. 2.3.1 contains details on Secure Boot. I wasn't able to locate any official policies or best practices. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 15 June 2012 15:58, Richard Farina wrote: > On 06/15/2012 03:12 AM, Ben de Groot wrote: >> On 15 June 2012 13:24, Arun Raghavan wrote: >>> On 15 June 2012 10:33, Ben de Groot wrote: On 15 June 2012 12:45, Arun Raghavan wrote: > On 15 June 2012 09:58, Greg KH wrote: >> So, anyone been thinking about this? I have, and it's not pretty. >> >> 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. > > Sounds like something the Gentoo Foundation could do. I'm certainly not the only one who would be averse to paying Microsoft any ransom money. >>> >>> And our refusal to pay for the signing affects precisely nobody except >>> for our users, who will have to jump through an extra hoop to make >>> their system work. >>> >>> On the flip side, having a simple way to use this infrastructure means >>> that people who care about security can get a chain of trust from the >>> firmware to the kernel (heck, maybe even userspace one day). This is >>> something that is worth having as well. >> >> I agree that security is a worthwhile goal. I just don't trust Microsoft. >> > It's more of a "pay us or your system can't boot" that I'm opposed to. That's why I called it ransom money. I'm very opposed to that too. But if we're talking about security and a chain of trust, then Microsoft has no place in that either. > Saying "I just don't trust Microsoft" is second to "I just don't trust > corporations that extort money from me just so I can boot". I don't > care who we are paying, I'm offended by the idea. If users can't build > their own fully functional boot loader that's an issue. > > I'm all for the signed "work-around signatures" idea as it is the least > objectionable... if such a thing is even possible. > > -Zero > -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 12:28 AM, Greg KH wrote: > 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. So, there are 22 posts already, so I'm going to try to cover a bunch of topics in one post. I've been thinking about this a fair bit. 1. Speaking as an individual trustee... The Gentoo Foundation legally speaks for Gentoo, can sign contracts, and can write checks. I don't really forsee any legal issues should we decide we want to pursue any kinds of relationships with MS or other entities associated with UEFI. Obviously any decision to actually pursue this would not be taken lightly. 2. From what I've heard the cost of getting a key that would be recognized by UEFI firmware is as low as a $99 one-time payment, and we pay many times that for stuff like trademark registration, corporate filing fees, not to mention hardware for infrastructure. Cost is likely a non-issue. 3. Freedom IS a big issue - my sense is that getting support from the powers that be for UEFI comes with a lot of strings. If we had a key the easiest solution would be to just write a signed GRUB stage1 that works exactly like the one we're all using, and it would load whatever you want, linux or windows or Stuxnet or otherwise. Once Malware writers start embedding our bootloader in their stuff I assume that the people issuing the keys will have the ability to revoke it (at least for new hardware). 4. Fedora is getting around #3 by making the whole thing a big trusted infrastructure - signature chains for all the kernel-space code. That meshes well with their whole /usr move initiative - you just have this big blog of stuff that you trust and never touch, and you can be sure you're running genuine RedHat goodness, just like all those iPhone users out there. :) 5. If somebody (perhaps under the umbrella of hardened) wanted to create a Gentoo project around a fully trusted Gentoo I'd be completely supportive of that. It would take work. In the spirit of Gentoo we should allow anybody to build their own signed with their own key, and perhaps we might have an official Gentoo-certified one that we would sign and the Foundation would obtain the necessary UEFI keys. However, that should be viewed as more of a service, and not a core offering - Gentoo will never depend on a piece of non-free software or metadata (and I'd probably lump a signing key into that category). The same tools (minus the private keys) used to generate any secure offering made by Gentoo should be available for users to use and sign their own systems. 6. At least on x86 users can either disable secure boot, or load their own signing keys. We should try to support both. While the full secure infrastructure of #5 will undoubtedly be a significant effort we could at least have the handbook have a section on how to sign your grub when building it and install it in a way that it can be used to boot (installing the keys themselves might be firmware-dependent, but to the extent that standards exist we can be helpful). 7. In general anybody who would be a happy Gentoo user should have no issues with signing their own bootloader, or disabling secure boot. 8. I think the bigger issue is with ARM, and I'm not personally clear on what the exact policy is there. That really strikes me as antitrust, but MS might argue that on ARM they have no monopoly (instead we have a bunch of different vendors who almost universally lock down their hardware). I can't really see how any solution that didn't give the end-user the ability to run arbitrary code on their machine could be called "Gentoo" so our ability to distribute signed bootloaders there is going to be limited. Maybe we create the ability to sign your own as with x86, and make the users pay the $99 for their own keys. As long as individual users don't distribute their "insecure" bootloaders they shouldn't be at risk of getting them revoked. Well, that's a lot, but those are my impressions. In short I see this as more of a speed-bump for x86, but a much more fundamental problem for ARM. Personally I never buy a general-purpose computing device like a PC or smartphone unless I know in advance that I can gain full control over it. Hopefully that option will remain open to me a lot longer. I'd be personally interested in pointers to info on what the "powers that be" do and don't allow with UEFI. I've seen lots of sky-is-falling blog entries and discussion but little in the way of specs, and more importantly, policies. Rich
Re: [gentoo-dev] UEFI secure boot and Gentoo
Am 15.06.2012 09:58, schrieb Richard Farina: > On 06/15/2012 03:12 AM, Ben de Groot wrote: >> On 15 June 2012 13:24, Arun Raghavan wrote: >>> On 15 June 2012 10:33, Ben de Groot wrote: On 15 June 2012 12:45, Arun Raghavan wrote: > On 15 June 2012 09:58, Greg KH wrote: >> So, anyone been thinking about this? I have, and it's not pretty. >> >> 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. > > Sounds like something the Gentoo Foundation could do. I'm certainly not the only one who would be averse to paying Microsoft any ransom money. >>> >>> And our refusal to pay for the signing affects precisely nobody except >>> for our users, who will have to jump through an extra hoop to make >>> their system work. >>> >>> On the flip side, having a simple way to use this infrastructure means >>> that people who care about security can get a chain of trust from the >>> firmware to the kernel (heck, maybe even userspace one day). This is >>> something that is worth having as well. >> >> I agree that security is a worthwhile goal. I just don't trust Microsoft. >> > It's more of a "pay us or your system can't boot" that I'm opposed to. > Saying "I just don't trust Microsoft" is second to "I just don't trust > corporations that extort money from me just so I can boot". I don't > care who we are paying, I'm offended by the idea. If users can't build > their own fully functional boot loader that's an issue. > > I'm all for the signed "work-around signatures" idea as it is the least > objectionable... if such a thing is even possible. > > -Zero > It is the most objectionable idea *I* can think of. Most importantly because it puts the Dev who volunteers to prove his or her identity to Verisign into a huge legal risk: Secure Boot is designed to prevent root kits. And whether you like it or not, it achieves this goal since it is a well designed system with few potential flaws. That means providing signature work-arounds which include your actual real name and other identifiable records (as they have to contain your public key) makes you an accessory to computer crimes. Besides, it wouldn't work long. They can blacklist keys. This isn't a half-arsed pseudo-secure system like DVD-CSS or WEP. We cannot break it in a 10 minute mailing list discussion. We have to play by the rules or don't play at all. Everything else will require years or decades of research. Regards, Florian Philipp Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
Am 15.06.2012 10:06, schrieb Richard Farina: > On 06/15/2012 03:49 AM, Florian Philipp wrote: >> Am 15.06.2012 09:26, schrieb Michał Górny: >>> On Thu, 14 Jun 2012 21:56:04 -0700 >>> Greg KH wrote: >>> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: > On 15 June 2012 09:58, Greg KH wrote: >> 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? > > I think it at least makes sense to talk about it, and work out what > we can and cannot do. > > 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? Distributing a first-stage bootloader blob, that is signed by Microsoft, or someone, seems to be the only way to easily handle this. >>> >>> Maybe we could get one such a blob for all distros/systems? >>> > >> I guess nothing prevents you from re-distributing Fedora's blob. > >>> Also, does this signature system have any restrictions on what is >>> signed and what is not? In other words, will they actually sign a blob >>> saying 'work-around signatures' on the top? >>> > >> They might sign it. I think it is just an automated process verified >> with smartcards. The point is, they will also blacklist it as soon as >> malware starts using it (or as soon as they are aware of the possibility). > >> It should also be noted that having a bootloader blob is not enough. You >> have to do it like Fedora and sign the kernel and modules as well as >> removing kernel features that could result in security breaches >> (everything outlined in [1]). I don't see any reasonable way to do this >> while allowing users to build their own kernel and third-party modules. > >> In the end, I think we'll need *-bin packages for everything running in >> kernel-space. > > Being all about choice I have to agree that as long as we have both bin > and normal kernels there is nothing wrong with that. However, dear god, > with how many kernels we have won't this get really expensive really > fast? Even just signing gentoo-sources and hardened-sources would cost > a fortune considering both change weekly if not daily. So that puts us > to signing just stable releases and damn users who want secure boot and > a recent kernel or need a custom patch? This all seems like a huge step > in the wrong direction to me, at the very least the amount of effort for > this is near insurmountable in my eyes. > > -Zero > > >> [1] http://mjg59.dreamwidth.org/12368.html > >> Regards, >> Florian Philipp > No, it won't be expensive. Please read the link in my message on how Fedora do it: 1. You pay 99$ *once* as a registration fee. After that, you can sign as much as you want. 2. In order to avoid the hassle of the actual authentication process for signing code, Fedora simply signs a stage-1 boot loader which then verifies all further stages against a custom Fedora key. This key also has to be secure but it means they can use their own, automated tool chain for signing kernel and grub builds. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2012 03:49 AM, Florian Philipp wrote: > Am 15.06.2012 09:26, schrieb Michał Górny: >> On Thu, 14 Jun 2012 21:56:04 -0700 >> Greg KH wrote: >> >>> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: On 15 June 2012 09:58, Greg KH wrote: > 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? I think it at least makes sense to talk about it, and work out what we can and cannot do. 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? >>> >>> Distributing a first-stage bootloader blob, that is signed by >>> Microsoft, or someone, seems to be the only way to easily handle this. >> >> Maybe we could get one such a blob for all distros/systems? >> > > I guess nothing prevents you from re-distributing Fedora's blob. > >> Also, does this signature system have any restrictions on what is >> signed and what is not? In other words, will they actually sign a blob >> saying 'work-around signatures' on the top? >> > > They might sign it. I think it is just an automated process verified > with smartcards. The point is, they will also blacklist it as soon as > malware starts using it (or as soon as they are aware of the possibility). > > It should also be noted that having a bootloader blob is not enough. You > have to do it like Fedora and sign the kernel and modules as well as > removing kernel features that could result in security breaches > (everything outlined in [1]). I don't see any reasonable way to do this > while allowing users to build their own kernel and third-party modules. > > In the end, I think we'll need *-bin packages for everything running in > kernel-space. Being all about choice I have to agree that as long as we have both bin and normal kernels there is nothing wrong with that. However, dear god, with how many kernels we have won't this get really expensive really fast? Even just signing gentoo-sources and hardened-sources would cost a fortune considering both change weekly if not daily. So that puts us to signing just stable releases and damn users who want secure boot and a recent kernel or need a custom patch? This all seems like a huge step in the wrong direction to me, at the very least the amount of effort for this is near insurmountable in my eyes. - -Zero > > [1] http://mjg59.dreamwidth.org/12368.html > > Regards, > Florian Philipp > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP2u0hAAoJEKXdFCfdEflKtPMP/3qpZ5klkvOnOfMm3anccpEm Zlo8T28+VwEjqt8m0hq/fWNteu4PbvzagD/jFLXym/OEW3w0XDFC8HI/JzbRVicT GAiv3s1zHV0yX/MzIeuSqDG+KnXJhuGige52Nxy2dyC8Ryq0kwOX90rHu2wXU8Z/ RQPuJgxf2Z34qBVNsZKHcH7caxcCUhHK+JmYwIE+hd4Y7vw1YjM49PAxLIQnhRvN lEQJt8lhyHzOzI7eScbQEtWRlGBRL/mtIoEkJa3iQb84hO9yfgAmxW512kZ4u5ZJ x8NVXaBPx6KmwdCugrryYNKMVSAUCvt08f2mPGOS2tyF3eFVcfUL3ZAzaN0Fdl+q 0nTgkq5LW0wwLB9woujuxrz949SL+g/JTH2clKZVQdwCX5w4Bt7KCeqKg6+eRhsB +9JoBZ9RYbmLQF5S+gjOuo/71Zds1IKtZIOcWp1jOdktph7udcCEvwJeQbAkK5jP rqT0jEhsTOy1RPIDBTXwLsV6/urKNCwit4nsoD+ZGHZ2GXL+OunheXJDFgfrGevD 5ownuPxa6WwLLtCd7S+6SgkcC65jamycs44IjKhoQXtsZUYOj6uBhlVIQymLFVsU r/ZeiOAilxiSP9QwTtZAohsninXQwIGxPbhwTrGp765uzalQoWzoz/Bop3IXdMgU jvY5FSvLQ9Da7RKrxC5W =XcZB -END PGP SIGNATURE-
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 06/15/2012 03:12 AM, Ben de Groot wrote: > On 15 June 2012 13:24, Arun Raghavan wrote: >> On 15 June 2012 10:33, Ben de Groot wrote: >>> On 15 June 2012 12:45, Arun Raghavan wrote: On 15 June 2012 09:58, Greg KH wrote: > So, anyone been thinking about this? I have, and it's not pretty. > > 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. Sounds like something the Gentoo Foundation could do. >>> >>> I'm certainly not the only one who would be averse to paying Microsoft >>> any ransom money. >> >> And our refusal to pay for the signing affects precisely nobody except >> for our users, who will have to jump through an extra hoop to make >> their system work. >> >> On the flip side, having a simple way to use this infrastructure means >> that people who care about security can get a chain of trust from the >> firmware to the kernel (heck, maybe even userspace one day). This is >> something that is worth having as well. > > I agree that security is a worthwhile goal. I just don't trust Microsoft. > It's more of a "pay us or your system can't boot" that I'm opposed to. Saying "I just don't trust Microsoft" is second to "I just don't trust corporations that extort money from me just so I can boot". I don't care who we are paying, I'm offended by the idea. If users can't build their own fully functional boot loader that's an issue. I'm all for the signed "work-around signatures" idea as it is the least objectionable... if such a thing is even possible. -Zero
Re: [gentoo-dev] UEFI secure boot and Gentoo
Am 15.06.2012 09:26, schrieb Michał Górny: > On Thu, 14 Jun 2012 21:56:04 -0700 > Greg KH wrote: > >> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: >>> On 15 June 2012 09:58, Greg KH wrote: 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? >>> >>> I think it at least makes sense to talk about it, and work out what >>> we can and cannot do. >>> >>> 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? >> >> Distributing a first-stage bootloader blob, that is signed by >> Microsoft, or someone, seems to be the only way to easily handle this. > > Maybe we could get one such a blob for all distros/systems? > I guess nothing prevents you from re-distributing Fedora's blob. > Also, does this signature system have any restrictions on what is > signed and what is not? In other words, will they actually sign a blob > saying 'work-around signatures' on the top? > They might sign it. I think it is just an automated process verified with smartcards. The point is, they will also blacklist it as soon as malware starts using it (or as soon as they are aware of the possibility). It should also be noted that having a bootloader blob is not enough. You have to do it like Fedora and sign the kernel and modules as well as removing kernel features that could result in security breaches (everything outlined in [1]). I don't see any reasonable way to do this while allowing users to build their own kernel and third-party modules. In the end, I think we'll need *-bin packages for everything running in kernel-space. [1] http://mjg59.dreamwidth.org/12368.html Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Thu, 14 Jun 2012 21:56:04 -0700 Greg KH wrote: > On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: > > On 15 June 2012 09:58, Greg KH wrote: > > > 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? > > > > I think it at least makes sense to talk about it, and work out what > > we can and cannot do. > > > > 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? > > Distributing a first-stage bootloader blob, that is signed by > Microsoft, or someone, seems to be the only way to easily handle this. Maybe we could get one such a blob for all distros/systems? Also, does this signature system have any restrictions on what is signed and what is not? In other words, will they actually sign a blob saying 'work-around signatures' on the top? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 15 June 2012 13:24, Arun Raghavan wrote: > On 15 June 2012 10:33, Ben de Groot wrote: >> On 15 June 2012 12:45, Arun Raghavan wrote: >>> On 15 June 2012 09:58, Greg KH wrote: So, anyone been thinking about this? I have, and it's not pretty. 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. >>> >>> Sounds like something the Gentoo Foundation could do. >> >> I'm certainly not the only one who would be averse to paying Microsoft >> any ransom money. > > And our refusal to pay for the signing affects precisely nobody except > for our users, who will have to jump through an extra hoop to make > their system work. > > On the flip side, having a simple way to use this infrastructure means > that people who care about security can get a chain of trust from the > firmware to the kernel (heck, maybe even userspace one day). This is > something that is worth having as well. I agree that security is a worthwhile goal. I just don't trust Microsoft. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 2012-06-15 7:56 AM, Greg KH wrote: > Distributing a first-stage bootloader blob, that is signed by Microsoft, > or someone, seems to be the only way to easily handle this. Fedora agrees: http://mjg59.dreamwidth.org/12368.html Other distros haven't decided yet afaik although there have been some discussions. > Also, some people might really want to sign their own bootloader and > kernel, and kernel modules (myself included) Yes, that is the goal we should try to achieve, i.e. to give the option to our users to sign all the way to userland. > Oh, and on the first-stage bootloader front, I already know of 2 simple, > and open source, examples that will work for Linux, so getting something > like that signed might not be very tough. It's the "where does the > chain-of-trust stop" question that gets tricky... Exactly. Do you have any concrete proposals? -- Eray Aslan signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] UEFI secure boot and Gentoo
120614 Greg KH wrote: > 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. > I did a lot of UEFI secure boot work in the past at SUSE > and should be soon a member of the UEFI "organization" > through my work at the Linux Foundation, so I do have a basic grasp > of the issues involved and have a chance to get changes made, > if needed and possible, to the spec itself. Does this affect those of us who build our own machines ? Is there likely to be any Gentoo user who is reluctant to change the default BIOS setting ? How can UEFI be required for Arm without running into anti-trust ? How far is this basically a problem for those in the USA, the rest of us having a different attitude to security issues ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 15 June 2012 10:33, Ben de Groot wrote: > On 15 June 2012 12:45, Arun Raghavan wrote: >> On 15 June 2012 09:58, Greg KH wrote: >>> So, anyone been thinking about this? I have, and it's not pretty. >>> >>> 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. >> >> Sounds like something the Gentoo Foundation could do. > > I'm certainly not the only one who would be averse to paying Microsoft > any ransom money. And our refusal to pay for the signing affects precisely nobody except for our users, who will have to jump through an extra hoop to make their system work. On the flip side, having a simple way to use this infrastructure means that people who care about security can get a chain of trust from the firmware to the kernel (heck, maybe even userspace one day). This is something that is worth having as well. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 15 June 2012 10:26, Greg KH wrote: > On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: >> On 15 June 2012 09:58, Greg KH wrote: >> > 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? >> >> I think it at least makes sense to talk about it, and work out what we >> can and cannot do. >> >> 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? > > Distributing a first-stage bootloader blob, that is signed by Microsoft, > or someone, seems to be the only way to easily handle this. > > Although all BIOSes will have the option to turn secure boot off, I > think it is something that we might not want to require for Gentoo to > work properly on those machines. > > Also, some people might really want to sign their own bootloader and > kernel, and kernel modules (myself included), so just getting that basic > infrastructure in place is going to take some work, no matter who ends > up signing the first-stage bootloader blob. I hadn't thought of that. I imagine the hardened team might be interested in making such infrastructure easily available as well. > Oh, and on the first-stage bootloader front, I already know of 2 simple, > and open source, examples that will work for Linux, so getting something > like that signed might not be very tough. It's the "where does the > chain-of-trust stop" question that gets tricky... For validating the chain of trust, it might be useful to make it possible for anyone to generate the same bootloader and verify the hashes themselves. For the truly paranoid maybe a signed stage3 + portage snapshot to generate the bootloader image from scratch. >> > 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. >> >> Sounds like something the Gentoo Foundation could do. > > Can they do that? I haven't been paying attention to if we are really a > legal entity still or not, sorry. I believe so, but quantumsummers is likely the best person to confirm. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 1:03 AM, Ben de Groot wrote: > On 15 June 2012 12:45, Arun Raghavan wrote: > > On 15 June 2012 09:58, Greg KH wrote: > >> So, anyone been thinking about this? I have, and it's not pretty. > >> > >> 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. > > > > Sounds like something the Gentoo Foundation could do. > > I'm certainly not the only one who would be averse to paying Microsoft > any ransom money. Last I heard Verisign was handling the signing certs, but that also doesn't mean MS isn't getting a cut of the profit. - Matt
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 15 June 2012 12:45, Arun Raghavan wrote: > On 15 June 2012 09:58, Greg KH wrote: >> So, anyone been thinking about this? I have, and it's not pretty. >> >> 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. > > Sounds like something the Gentoo Foundation could do. I'm certainly not the only one who would be averse to paying Microsoft any ransom money. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead
Re: [gentoo-dev] UEFI secure boot and Gentoo
Greg KH schrieb: > 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. For the current crop of hardware, it is probably sufficient to add a paragraph to the handbook which tells the user to disable secure boot. Getting users' self-compiled boot loaders signed with a Gentoo key is probably infeasible. If you have influence on UEFI secure boot spec, you could suggest that they mandate a UI which lists all boot images known to the EFI boot manager, and the user can easily whitelist both individual loaders and the keys used to sign them. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote: > On 15 June 2012 09:58, Greg KH wrote: > > 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? > > I think it at least makes sense to talk about it, and work out what we > can and cannot do. > > 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? Distributing a first-stage bootloader blob, that is signed by Microsoft, or someone, seems to be the only way to easily handle this. Although all BIOSes will have the option to turn secure boot off, I think it is something that we might not want to require for Gentoo to work properly on those machines. Also, some people might really want to sign their own bootloader and kernel, and kernel modules (myself included), so just getting that basic infrastructure in place is going to take some work, no matter who ends up signing the first-stage bootloader blob. Oh, and on the first-stage bootloader front, I already know of 2 simple, and open source, examples that will work for Linux, so getting something like that signed might not be very tough. It's the "where does the chain-of-trust stop" question that gets tricky... > > 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. > > Sounds like something the Gentoo Foundation could do. Can they do that? I haven't been paying attention to if we are really a legal entity still or not, sorry. greg k-h
Re: [gentoo-dev] UEFI secure boot and Gentoo
On Thu, Jun 14, 2012 at 09:28:10PM -0700, Greg KH wrote: > 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. Oh, and for those that don't know, I did a lot of UEFI secure boot work in the past at SUSE, and should be soon a member of the UEFI "organization" through my work at the Linux Foundation, so I do have a basic grasp of the issues involved, and have a chance to get changes made, if needed, and possible, to the spec itself. greg k-h
Re: [gentoo-dev] UEFI secure boot and Gentoo
On 15 June 2012 09:58, Greg KH wrote: > 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? I think it at least makes sense to talk about it, and work out what we can and cannot do. 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? > 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. Sounds like something the Gentoo Foundation could do. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
[gentoo-dev] UEFI secure boot and Gentoo
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. thanks, greg k-h
