Re: [gentoo-dev] Killing UEFI Secure Boot
On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote: I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. You have a much better chance of just telling the user, Disable the Secure Boot option in your BIOS. No, that doesn't mean that Linux isn't secure. Yes, I understand it looks that way. And the conversation degenerates from there. Sorry, not a valid solution. And I want secure boot on my machines, with a key I trust, don't you? If not, why not? I know lots of others that also want this, why deny them the ability to run Gentoo on their hardware? greg k-h
Re: [gentoo-dev] Killing UEFI Secure Boot
On 06/20/2012 04:08 PM, Greg KH wrote: On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote: I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. OpenWRT does that with routers and Cyanogenmod does that with phones. It seems reason for us to offer it as an option to users. With that said, this probably won't happen. One of the Core Boot developers informed me of what is involved in setting up the address space and it is infeasible for us to do. And I want secure boot on my machines, with a key I trust, don't you? If not, why not? I know lots of others that also want this, why deny them the ability to run Gentoo on their hardware? To be clear, I was not talking about taking away options from users. I was talking about giving them options.
Re: [gentoo-dev] Killing UEFI Secure Boot
On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote: On 06/20/2012 04:08 PM, Greg KH wrote: On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote: I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. OpenWRT does that with routers and Cyanogenmod does that with phones. No, neither of them replaces the BIOS in their machines with an opensource version. There is no BIOS in those platforms, it's just uboot or fastboot, the PC-like ecosystem is so vastly different it's laughable. It seems reason for us to offer it as an option to users. With that said, this probably won't happen. One of the Core Boot developers informed me of what is involved in setting up the address space and it is infeasible for us to do. And I agree with that developer. Don't get replace all of userspace and the kernel confused with replace the UEFI bios. You do realize that the UEFI bios is at least double the size of the Linux kernel, with custom device drivers and tons of other stuff in there? Good luck replacing that... And I want secure boot on my machines, with a key I trust, don't you? If not, why not? I know lots of others that also want this, why deny them the ability to run Gentoo on their hardware? To be clear, I was not talking about taking away options from users. I was talking about giving them options. You are taking secure boot out of their systems, that sounds like taking away an option to me :) Anyway, it's all a moot point, as has been explained already, sorry. greg k-h
Re: [gentoo-dev] Killing UEFI Secure Boot
On 06/20/2012 04:20 PM, Greg KH wrote: On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote: On 06/20/2012 04:08 PM, Greg KH wrote: On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote: I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. OpenWRT does that with routers and Cyanogenmod does that with phones. No, neither of them replaces the BIOS in their machines with an opensource version. There is no BIOS in those platforms, it's just uboot or fastboot, the PC-like ecosystem is so vastly different it's laughable. The BIOS on our machines is analogous to the flash on those machines on which the firmware operates. There is no difference. It seems reason for us to offer it as an option to users. With that said, this probably won't happen. One of the Core Boot developers informed me of what is involved in setting up the address space and it is infeasible for us to do. And I agree with that developer. Don't get replace all of userspace and the kernel confused with replace the UEFI bios. You do realize that the UEFI bios is at least double the size of the Linux kernel, with custom device drivers and tons of other stuff in there? Good luck replacing that... Replacing UEFI does not mean that we need a compatible replacement. Things like being able to boot Windows is unnecessary functionality that can be removed. The only thing replacement firmware must do is get the kernel loaded into memory, initialize the structures that the kernel wants and jump into it. That is it. And I want secure boot on my machines, with a key I trust, don't you? If not, why not? I know lots of others that also want this, why deny them the ability to run Gentoo on their hardware? To be clear, I was not talking about taking away options from users. I was talking about giving them options. You are taking secure boot out of their systems, that sounds like taking away an option to me :) I have an Asus motherboard that fails to boot when it has more than 6 hard drives. If I replaced its BIOS with our own firmware, I could fix that. If I had our own firmware and I wanted to do my own key signing, I could implement that. If were to replace UEFI with our own firmware, the user would have full view of the source code, rather than some mystery blob. The pool of people who could do bug fixes would increase and that in general would be a good thing. Technical hurdles will likely prevent this unless we an get vendors to release documentation. Is there any chance you could contact people at Intel requesting programming documentation on their memory controller and anything else we would need to write a small OS that we could flash in place of UEFI?
Re: [gentoo-dev] Killing UEFI Secure Boot
On Wed, Jun 20, 2012 at 04:35:41PM -0400, Richard Yao wrote: On 06/20/2012 04:20 PM, Greg KH wrote: On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote: On 06/20/2012 04:08 PM, Greg KH wrote: On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote: I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. OpenWRT does that with routers and Cyanogenmod does that with phones. No, neither of them replaces the BIOS in their machines with an opensource version. There is no BIOS in those platforms, it's just uboot or fastboot, the PC-like ecosystem is so vastly different it's laughable. The BIOS on our machines is analogous to the flash on those machines on which the firmware operates. There is no difference. There is a huge difference here, please do a bit of research before claiming otherwise. It seems reason for us to offer it as an option to users. With that said, this probably won't happen. One of the Core Boot developers informed me of what is involved in setting up the address space and it is infeasible for us to do. And I agree with that developer. Don't get replace all of userspace and the kernel confused with replace the UEFI bios. You do realize that the UEFI bios is at least double the size of the Linux kernel, with custom device drivers and tons of other stuff in there? Good luck replacing that... Replacing UEFI does not mean that we need a compatible replacement. Things like being able to boot Windows is unnecessary functionality that can be removed. The only thing replacement firmware must do is get the kernel loaded into memory, initialize the structures that the kernel wants and jump into it. That is it. A BIOS does much much more than just that. See the coreboot code for examples of what needs to happen to get a x86-like machine up and running to the point at which it is possible to hand off control to a bootloader. And I want secure boot on my machines, with a key I trust, don't you? If not, why not? I know lots of others that also want this, why deny them the ability to run Gentoo on their hardware? To be clear, I was not talking about taking away options from users. I was talking about giving them options. You are taking secure boot out of their systems, that sounds like taking away an option to me :) I have an Asus motherboard that fails to boot when it has more than 6 hard drives. If I replaced its BIOS with our own firmware, I could fix that. If I had our own firmware and I wanted to do my own key signing, I could implement that. If were to replace UEFI with our own firmware, the user would have full view of the source code, rather than some mystery blob. The pool of people who could do bug fixes would increase and that in general would be a good thing. You do realize that the majority of the UEFI code is opensource, right? That's not the hard part here, the response from the coreboot developer should have given you a glimpse into the real difficulties involved. Technical hurdles will likely prevent this unless we an get vendors to release documentation. Is there any chance you could contact people at Intel requesting programming documentation on their memory controller and anything else we would need to write a small OS that we could flash in place of UEFI? Again, see the response from Peter about what is needed here. That anything else is not trivial. But feel free to prove me wrong, I love it when that happens :) greg k-h
Re: [gentoo-dev] Killing UEFI Secure Boot
On 06/20/2012 05:09 PM, Greg KH wrote: Technical hurdles will likely prevent this unless we an get vendors to release documentation. Is there any chance you could contact people at Intel requesting programming documentation on their memory controller and anything else we would need to write a small OS that we could flash in place of UEFI? Again, see the response from Peter about what is needed here. That anything else is not trivial. But feel free to prove me wrong, I love it when that happens :) greg k-h You must not have read this, where I said that I realized that this is infeasible: On 06/20/2012 04:13 PM, Richard Yao wrote: Stop right there. That's just not going to happen, sorry. You aren't going to be able to get a user to replace their BIOS, nor should you ever want to. You are not going to be able to keep up with the hundreds, if not thousands, of different motherboards being introduced every month, in order to just get rid of the secure boot option. OpenWRT does that with routers and Cyanogenmod does that with phones. It seems reason for us to offer it as an option to users. With that said, this probably won't happen. One of the Core Boot developers informed me of what is involved in setting up the address space and it is infeasible for us to do. From what I can tell, the Core Boot developers could use that documentation. You yourself said If there's anything that anyone is thinking I should be doing but seem not to be, please let me know.. Do you have any intention of acting on that?
[gentoo-dev] Killing UEFI Secure Boot
I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. With that in mind, I believe we can solve the Secure Boot problem by installing Gentoo on PC hardware like how OpenWRT is installed on routers. http://wiki.openwrt.org/doc/techref/flash.layout We can extend genkernel to produce images similar OpenWRT images. This image would have partitions. In particular, it would have one for the bootloader, another for the kernel and a third for an optional root filesystem. The bootloader partition would be further divided between boot code and the NVRAM, which would contain bootloader settings. The bootloader would read the NVRAM to obtain the kernel command line that it provides to the kernel and then boot it. THe kernel would then be responsible for initializing hardware and mounting the rootfs. We will need boot code designed to start after RESET, read the NVRAM, configure the memory address space, load the kernel and jump into it. It would also handle any other things that either the kernel requires or that users want, such as a VGA text console before the kernel boots. A VGA console will require additional documentation from vendors, but routers seem to boot fine without it and our systems should too. x86 hardware emulates an 80386 environment at RESET, so we should be able to use documentation on 80386 to assist in development: http://css.csail.mit.edu/6.858/2011/readings/i386.pdf Das U-Boot and RedBoot are typically used on routers, but unlike RedBoot, Das U-Boot supports x86. In addition, the knowledge and tools necessary to develop on physical hardware are quite accessible: http://openschemes.com/2009/10/20/installing-a-plcc-eeprom-socket-onto-a-mobo/ http://www.sivava.com/EPROM_Programmer_5.html Developing on physical hardware could be tedious and time consuming, so it would probably be best to develop this on virtual hardware first. VMWare in particular uses a Phoenix BIOS. My expectation is that developing this on VMware's virtual hardware will help avoid issues when development moves to physical hardware. In addition, instructions are available for booting custom BIOS images, which is precisely what we need to develop this: http://pete.akeo.ie/2011/06/extracting-and-using-modified-vmware.html I know that the Core Boot project also tries to accomplish this, but their development process is slow and their approach seems to make the boot process more complicated than it needs to be. Since Secure Boot will force us to flash our BIOS chips (or stick to old hardware), I think it would be worthwhile to develop our own solution by extending genkernel. This should have the benefit of making our systems boot faster. This should open the door to further genkernel extensions, such as the creation of an initramfs that provides a general purpose GRUB replacement. This would enable us to flash the BIOS only once and then boot newer kernels (or even other operating systems) by adding entries to the NVRAM. It would still be faster than Core Boot because the kernel in the BIOS chip should still be able to mount the rootfs and boot the system. Does anyone have any thoughts, comments or suggestions? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Killing UEFI Secure Boot
On Tue, Jun 19, 2012 at 6:11 PM, Richard Yao r...@gentoo.org wrote: I know that the Core Boot project also tries to accomplish this, but their development process is slow and their approach seems to make the boot process more complicated than it needs to be. Since Secure Boot will force us to flash our BIOS chips (or stick to old hardware), I think it would be worthwhile to develop our own solution by extending genkernel. This should have the benefit of making our systems boot faster. So, replacing a BIOS is a fairly tall order - I'm not convinced that Core Boot is slow simply because they're doing it wrong. They're also looking to add value (like booting a diskless server off of a random website or whatever - not just simple disk/PXE like most BIOS). My understanding is that clusters are one of their big use cases. I also don't get the claim that we need to flash our BIOS chips to get around secure boot. If you don't want to use secure boot just disable it - it is no harder than changing your boot device order, system time, or any of a myriad of other firmware settings. It gets more complicated if you want to keep secure boot but boot your own OS, since you have to manage the keys/signing/etc. Nothing is keeping anybody from creating their own firmware. However, I doubt we'll see 25 devs take this on as a full-time job, which is probably what it would take to support the bazillions of boards out there. Keep in mind that many motherboard vendors require signed firmware so you'll need to find an exploit for every make/model out there to even load your firmware. That seems a bit much compared to just disabling secure boot... Rich
Re: [gentoo-dev] Killing UEFI Secure Boot
On 06/19/2012 08:22 PM, Rich Freeman wrote: On Tue, Jun 19, 2012 at 6:11 PM, Richard Yao r...@gentoo.org wrote: I know that the Core Boot project also tries to accomplish this, but their development process is slow and their approach seems to make the boot process more complicated than it needs to be. Since Secure Boot will force us to flash our BIOS chips (or stick to old hardware), I think it would be worthwhile to develop our own solution by extending genkernel. This should have the benefit of making our systems boot faster. So, replacing a BIOS is a fairly tall order - I'm not convinced that Core Boot is slow simply because they're doing it wrong. They're also looking to add value (like booting a diskless server off of a random website or whatever - not just simple disk/PXE like most BIOS). My understanding is that clusters are one of their big use cases. Core Boot is a Linux distribution. I do not think that we should boot Gentoo using their distribution any more than we boot Gentoo using RHEL. I also don't get the claim that we need to flash our BIOS chips to get around secure boot. If you don't want to use secure boot just disable it - it is no harder than changing your boot device order, system time, or any of a myriad of other firmware settings. It gets more complicated if you want to keep secure boot but boot your own OS, since you have to manage the keys/signing/etc. In theory, the kernel could be modified to only execute signed binaries and portage could be modified to produce signed binaries. The user could build a system that required everything to be signed with the private key of his choice. A hardened system that required signed binaries would be even more secure than a typical system using Secure Boot where only the bootloader, kernel and kernel modules are signed. The user would be in full control of his hardware. The user would not need to pay for this and the system would also boot faster. Nothing is keeping anybody from creating their own firmware. However, I doubt we'll see 25 devs take this on as a full-time job, which is probably what it would take to support the bazillions of boards out there. Keep in mind that many motherboard vendors require signed firmware so you'll need to find an exploit for every make/model out there to even load your firmware. That seems a bit much compared to just disabling secure boot... The 80386's RESET state is emulated uniformly across all x86 and amd64, so it should not take much effort to support the basic functions of setting up the CPU, loading the kernel (from the EEPROM) and jumping into it. Everything else is secondary. Those are the only things that a BIOS replacement needs to do. As you pointed out, Core Boot is trying to add value. That means that they are doing far more than those basic functions. Other features are nice, but not if they get in the way of being able to boot. Other things can come the system boot process works. Basic functionality would only require the work of a few people. Things beyond that (e.g. pre-kernel VGA console initialization, pre-kernel networking, etcetera) might require vendor support through documentation. I would be thrilled if 25 developers wanted to work on this full time, but I am not certain that would make sense. Linux already has thousands of developers working on hardware support, including developers from Intel. We should be able to leverage that. Did I miss any technical obstacles?
Re: [gentoo-dev] Killing UEFI Secure Boot
On Tue, Jun 19, 2012 at 9:10 PM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 08:22 PM, Rich Freeman wrote: Core Boot is a Linux distribution. I do not think that we should boot Gentoo using their distribution any more than we boot Gentoo using RHEL. Well, maybe it is a distro in the sense that genkernel or dracut are distros (they bundle a bunch of tools in conjunction with a kernel to do something). The whole point of Core Boot is to be a BIOS replacement - either to do work on its own, or to boot something else. Like UEFI it aims to do more than just load one sector off the hard drive, check for a magic number, and jump into it. In theory, the kernel could be modified to only execute signed binaries and portage could be modified to produce signed binaries. The user could build a system that required everything to be signed with the private key of his choice. A hardened system that required signed binaries would be even more secure than a typical system using Secure Boot where only the bootloader, kernel and kernel modules are signed. The user would be in full control of his hardware. The user would not need to pay for this and the system would also boot faster. You can do all of this with the UEFI firmware that will come with your computer already. Why replace it? The 80386's RESET state is emulated uniformly across all x86 and amd64, so it should not take much effort to support the basic functions of setting up the CPU, loading the kernel (from the EEPROM) and jumping into it. Everything else is secondary. Fair enough, and the fact is that most modern OSes depend little on the BIOS for much of anything. I'm not sure that is absolutely nothing, but obviously the Core Boot folks have it working in some cases. Those are the only things that a BIOS replacement needs to do. As you pointed out, Core Boot is trying to add value. That means that they are doing far more than those basic functions. Other features are nice, but not if they get in the way of being able to boot. Other things can come the system boot process works. Did I miss any technical obstacles? Honestly, I'd probably ask one of the Core Boot folks. Has anybody already tried to make a core boot light? If their system already works on any board out there, then we're re-inventing the wheel. If theirs doesn't, then we need to ask why, since we're likely to run into the same barriers. In any case, this seems like a solution to a problem that we don't have. Any win7-certified motherboard is doing to be able to boot without secure boot just fine, so why do we need to replace it with a minimal firmware that does the same thing? I can see why one might want to improve on it, with Core Boot and such. However, I suspect the last thing we want in the Gentoo handbook is for every newbie to be flashing a Gentoo-made firmware onto their board and we get to deal with the bricks. Rich
Re: [gentoo-dev] Killing UEFI Secure Boot
On 06/19/2012 09:25 PM, Rich Freeman wrote: In theory, the kernel could be modified to only execute signed binaries and portage could be modified to produce signed binaries. The user could build a system that required everything to be signed with the private key of his choice. A hardened system that required signed binaries would be even more secure than a typical system using Secure Boot where only the bootloader, kernel and kernel modules are signed. The user would be in full control of his hardware. The user would not need to pay for this and the system would also boot faster. You can do all of this with the UEFI firmware that will come with your computer already. Why replace it? We would gain a faster boot process. We would also enable people to avoid paying money for keys that can be revoked without a refund. I would rather people make donations to the Gentoo Foundation voluntarily than to Verisign out of necessity, but that is just me.
Re: [gentoo-dev] Killing UEFI Secure Boot
On Tue, Jun 19, 2012 at 9:33 PM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 09:25 PM, Rich Freeman wrote: We would gain a faster boot process. We would also enable people to avoid paying money for keys that can be revoked without a refund. While I have no doubt that a determined team could make a firmware that booted marginally faster, I don't get the bit about not paying for keys. You don't have to pay anybody for a key to boot with UEFI - you just need to either disable secure boot, or install your own keys. I can't see how installing your own keys is going to be harder than flashing the entire BIOS, and if you still want secure boot presumably you still have to install your own keys. If somebody wants to make a generic UEFI bootloader for PCs they should by all means do so - I'm sure people would find use for it. I just don't see it as an essential ingredient for Gentoo. If I really wanted to mess with my BIOS I'd probably be loading core boot on it. Rich
Re: [gentoo-dev] Killing UEFI Secure Boot
Hi, I have about 11 years of experience with coreboot. I got involved while developing a custom BIOS for an embedded system. You may already have caught some presentation I or one of the other developers have made about the project. There's a bunch of links over at http://www.coreboot.org/Screenshots Richard Yao wrote: Core Boot is a Linux distribution. Sorry sir, but no. coreboot (one word, lowercase) is an open source BIOS replacement. Proprietary BIOSes do two things: 1. hardware initialization on http://stuge.se/pc2010.png everything red requires init by firmware 2. starts an operating system this means implementing the BIOS Boot Specification, running master boot record code into real mode segment 7c00h, eltorito CD-ROM extensions and all of that crap coreboot does step 1. and nothign else, and significantly faster than common proprietary BIOSes. When coreboot is done it starts another, separate, program, we call that program the payload. The payload and coreboot are stored together in the boot flash, but are not linked together. The payload can be any bare-metal program. There are many legacy-free bootloader payloads, including GRUB2 and gPXE/iPXE/whateverit'scalledtoday, but it can just as easily be an operating system kernel or an embedded application if no OS is needed. Boot flash are often 32Mbit today, so Linux and a small initramfs fits comfortably. The default payload is SeaBIOS, which is also the firmware QEMU uses. SeaBIOS is an open source legacy BIOS implementation, and the combination of coreboot and SeaBIOS provides a legacy-compatible boot environment that starts your system exactly like an old-fashioned proprietary BIOS. With coreboot my laptop boots from power button to firefox in a little over 8 seconds. Out of that time, coreboot runs for about 600 milliseconds. This is a fairly typical number. The 80386's RESET state is emulated uniformly across all x86 and amd64, so it should not take much effort to support the basic functions of setting up the CPU, loading the kernel (from the EEPROM) and jumping into it. This is word for word what the founders of the coreboot project (then called LinuxBIOS) thought back in 1999, and it blew up in their face. In the following 15 years hardware has gotten significantly more complex, and significantly more closed, again please have a look at http://stuge.se/pc2010.png The closer you are to the CPU the more impossible it is to acquire reliable documentation for how to program the hardware. Those are the only things that a BIOS replacement needs to do. Please join the project! If you find lowlevel programming interesting it is an amazing good time, even if progress is slow at times. Now is a fantastic time to get involved! For the first time in the history of the project, there is code in the repository for all current hardware platforms from both AMD and Intel. they are doing far more than those basic functions I hope I've been able to clarify that actually coreboot does nothing other than what is neccessary. This is the very essence of coreboot. Basic functionality would only require the work of a few people. I'm afraid that this is rather naive. An experienced coreboot developer given all required documentation[1] (and ideally some 100-1000k EUR/USD worth of test equipment) can possibly do a port to a new hardware platform (new CPU and chipset) in twelve to eighteen months full time. A hard core developer but without previous experience from PC firmware and coreboot should add some six months for loading the domain into her head. [1] For Intel this requires two stages of NDAs and a decent business case where Intel will sell five-six figure amounts of chips, or fewer chips but to an important customer. In contrast, AMD put the documentation on their webpage. NVIDIA did not give the documentation to anyone no matter what the business case. VIA doesn't publish documentation on the web, but some coreboot developers do have good relations with them. Over the last couple years Google have hired most of the active coreboot developers including the project founder, and they've been working on support for Intel's Sandy Bridge and Ivy Bridge platforms, which powers the new Chromebook. I do not know how much time they've spent, but from my outside view I estimate that it took this amazing team of engineers between 25 and 30 man-months. This may be a very optimistic estimate. These new Intel platforms require a blob, firmware for a microcontroller in the chipset, which runs while the main CPU is still held in reset, in order to do some early prepararation of the system. The firmware blob is signed by Intel. I don't know if the signature scheme has been broken, I guess it might at some point, but that will likely be by the usual IT security crowd suspects. In Google's coreboot code they are using Intel's reference code for initializing the memory controller. This is so far also a blob, again as
