Is TianoCore+coreboot a true open source UEFI?

There has been a lot of controversy surrounding UEFI, but like it or not, it's becoming the only option when it comes to generally available desktop motherboards. I've been avoiding UEFI mobos for some time, but now it became quite difficult as mobo vendors ship UEFI products with more features than BIOS ones (i.e. support for more RAM). That in mind, I want to be sure that there's at least an option to go open source in the future, and if there isn't, I can bear with less features but more freedom.

TianoCore is Intel's open source implementation of UEFI interfaces and Wikipedia has this to say about it:

TianoCore lacks the specialized drivers that initialize chipset functions, which are instead provided by Coreboot, of which TianoCore is one of many payload options. The development of Coreboot requires cooperation from chipset manufacturers to provide the specifications needed to develop initialization drivers.

My question is, do these drivers provided by coreboot still require some kind of binary blobs from chipset vendors? Also, Ronald G. Minnich has this to say about EFI:

Accesses to IDE I/O addresses, or certain memory addresses, can be trapped to EFI code and potentially examined and modified or aborted. Many see this as an effort to build a "DRM BIOS".

In a TianoCore+coreboot setup, are parts that could potentially do that open source or binary firmware provided by hardware vendor?

Solution 1:

Is TianoCore+coreboot a true open source UEFI?

For Intel platforms(I have done development for Intel boards and I cannot speak for AMD though I believe the case is still the same), no, because TianoCore by itself cannot perform low level hardware initialization and requires coreboot to do this hardware init first. But how does coreboot do this? coreboot invokes specific binary blobs to perform these functions. How are these binary blobs(e.g. microcode updates, FSP binaries, ME binaries, etc) generated? Well you cannot build these binaries yourself because they are Intel proprietary code. At best, you can retrieve the ones pertinent to your platform and have them included in the coreboot build process. Until you are able to freely and openly modify the source for these binary blobs you will not have a true open source UEFI or coreboot for that matter.

My question is, do these drivers provided by coreboot still require some kind of binary blobs from chipset vendors?

Yes

Sources:

Experience

coreboot source code

http://www.coreboot.org/TianoCore

Intel Firmware Support Package(FSP)
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html

Microcode Update (Often applied by the BIOS but doesn't have to.)
https://wiki.debian.org/Microcode

Solution 2:

It's possible to combine coreboot (doing early hardware initialization) and TianoCore (providing the UEFI API) to a complete UEFI firmware implementation. However that's still in development. It also won't be a "canonical" UEFI since the outer layer will be coreboot.

One approach, based on Duet, can be found at http://notabs.org/coreboot/duet-payload/ - it boots somewhat on real hardware.

Another (disclosure: my project) attempt that tries to reuse more of Tiano and stay closer to the UEFI architecture is on github: https://github.com/pgeorgi/edk2/. This one hasn't seen much testing on real hardware yet, just Qemu.

In principle it could also work to take coreboot code and make tianocore packages out of them, so it looks and feels like UEFI in every aspect (not just those visible to the user and the OS). Obviously coreboot developers aren't very interested in that.

Solution 3:

Chipset initialization and such other extremely low-level hardware specific code has always been mostly closed-source. BIOS/UEFI does not change the fact that details of memory controller initialization etc. are rarely disclosed by board vendors.

To have a true open-source board, you'll have to look for open-source hardware, some vendor who exposes all the specifications of each hardware component on the motherboard. That's difficult to find, to say the least.