Concern over growing reach of proprietary firmware BLOBs

Just because it's on Github doesn't mean you can read it.

Vendors of the FOSS hardware and software communities are voicing their concerns about closed-source firmware.

Virtually impenetrable BLOBs (Binary Large Objects) in firmware mean it's difficult to be sure exactly what the computer is doing. Assuming the BLOBs are unencrypted, and they usually are, you'll have to break out a disassembler to figure out what the code does, which requires skills and knowledge, and is tedious – especially if the binary is obfuscated.

Hardware vendors provide software, too. You can't boot a computer without multiple pieces of code in various flash ROMs – to initialize the processor, the disk drives, and the chips that connect them. As computers get more complex, so does their firmware. More layers of code not only means more potential vulnerabilities, it means they can be hidden from the running OS. This requires blind trust, which is a strong motivator for keeping the source code of such code open.

For the very privacy-conscious, there are x86 laptops such as Purism's Librem machines which use the coreboot open-source firmware, which is also used in Chromebooks.

It's not only for consumer kit. So does the LinuxBoot firmware for servers, which is backed by Google and Facebook via the Open Compute Project. Despite some controversy, it's working on version 2 of its spec. Both coreboot and LinuxBoot use Intel's FSP (Firmware Support Package) to initialize the hardware.

In the wonderful modern world of UEFI and suchlike, even your firmware has firmware

LinuxBoot grew out of Google's NERF project, which was driven by concern about security holes in the Intel Management Engine, as well as scary attacks like Thunderstrike and Thunderstrike 2.

NERF, for reference, stood for Non-Extensible Reduced Firmware, an intentional contrast with UEFI: Unified Extensible Firmware Interface. Way back when we described the origins of virtualisation, we covered the concept of "protection levels" and rings 0, 1, 2 and 3. Hypervisors introduced "ring -1" to this, Intel's SMM brought in ring -2, and now management tools add ring -3 [PDF].

As of version 2.0, Intel hosted FSP on GitHub, under a very simple licence. For amusement, compare that with the previous version. Now, Philipp Deppenwiese the Open Source Firmware Foundation is saying that FSP 3.0 will go closed-source again.

Can you trust your memory?

But wait, there's more to come. As our sister site the Next Platform described in depth, IBM's Power10 chips include a "memory area network". This is used in high-end kit such as the E1080… and that is where another proprietary-firmware issue pops up.

These are expandable servers, but they need very high speed memory. That prevents them from using methods such as the unified memory in Apple's M1, where the machine's RAM is in the same package as the CPU and GPU. Instead, IBM's Power10 puts its RAM on a serial bus, called the OpenPOWER Memory Interface (OMI). OMI memory modules are called Differential DIMMs or D-DIMMs, and they communicate intelligently with the processor. That means local software on the D-DIMMs, meaning local firmware. Power10 also has an on-chip PPE I/O processor, which also needs code – and although that code is on GitHub, it contains at least one BLOB, probably for a Synopsis PCIe-5 controller.

Currently, just one vendor, Raptor, makes POWER-based workstations, and one of its selling points is open firmware throughout. For now, that makes it unable to adopt Power10, much as it would like to. This is an issue that seems unlikely to improve in the near future, unless customer resistance limits sales and forces vendors to be more open. ®