Libreboot To Provide New Firmware ROMs With CPU Microcode Removed

[phoronix]

Phoronix: Libreboot To Provide New Firmware ROMs With CPU Microcode Removed

CPU microcode updates are commonly done in the name of security fixes and resolving functionality issues.. In recent years, CPU microcode updates have been a much more common -- and important -- occurrence. While all modern CPUs rely on microcode it's just a matter of whether the version used is baked into the hardware or an updated version loaded by the BIOS or OS at boot time, a "vocal minority" of users are unhappy with CPU microcode being included in Libreboot ROMs. Thus moving forward there will be alternative builds of Libreboot for different motherboards with the CPU microcode stripped out in the name of software freedom...

https://www.phoronix.com/news/Libreboot-Strip-The-CPU-ucode

[rob-tech]

Doesn't make any sense, ridiculous really, you still need to use a microcode and the only difference is that now you will be using an outdated version with more errata that was baked into your processor during manufacturing, making it years old possibly with performance and security issues. This is not logical I'm afraid and doesn't help your so called software freedom one bit.

[amxfonseca]

This is exactly how you get to achieve software freedumb™

[dylanmtaylor]

Well, that's moronic. You still need the microcode but now you don't have security and bug fixes.

So much more freedom /s

[ryao]

These guys should use FPGA soft cores. Speaking of which, I really would like to see more options in that area to create an option that lets anyone fix otherwise unfixable hardware defects in what would typically be black boxes.

With FPGA soft cores, you just reprogram the FPGA after synthesizing the verilog to fix flaws. No microcode is necessary. The downsides are high costs for large FPGAs, low clock speeds and the cores available are nothing like the latest AMD, Apple, Intel and IBM cores in terms of IPC.

People are beginning to do this, but it has yet to become popular.

https://github.com/litex-hub/linux-on-litex-vexriscv

[rawr]

Doesn't make any sense, ridiculous really, you still need to use a microcode and the only difference is that now you will be using an outdated version with more errata that was baked into your processor during manufacturing, making it years old possibly with performance and security issues. This is not logical I'm afraid and doesn't help your so called software freedom one bit.

That's why it's the default option to keep microcode updates in.

[Developer12]

It's worth noting a few things:

Libreboot recently moved to shipping microcode updates by default. This is mostly about a vocal minority being able to opt back out. Part of that is re-introducing workarounds for the broken microcode.

The microcode patches loaded are (by necessity) much, much smaller than the completely-unvetted microcode that has been in the CPU since it was built. They are patches, after all.

Without this microcode, these processors suffer from broken frequency control, broken reboot behavior, and instability under heavy load.

[qarium]

These guys should use FPGA soft cores. Speaking of which, I really would like to see more options in that area to create an option that lets anyone fix otherwise unfixable hardware defects in what would typically be black boxes.

With FPGA soft cores, you just reprogram the FPGA after synthesizing the verilog to fix flaws. No microcode is necessary. The downsides are high costs for large FPGAs, low clock speeds and the cores available are nothing like the latest AMD, Apple, Intel and IBM cores in terms of IPC.

People are beginning to do this, but it has yet to become popular.

https://github.com/litex-hub/linux-on-litex-vexriscv

these FPGAs already become popular for example Mega65 (commodore64) and VampirV4 (Amiga) and MiSTer for ao486 DOS/486

[Morty]

These guys should use FPGA soft cores.

With FPGA soft cores, you just reprogram the FPGA after synthesizing the verilog to fix flaws.

Sure, just run the highly optimized proprietary closed source synthesizing tool to make the binary to download to the FPGA. No problem 🙊

[rawr]

Sure, just run the highly optimized proprietary closed source synthesizing tool to make the binary to download to the FPGA. No problem 🙊

Luckly there are smart people working on open tools for stuff like this too:

https://f4pga.readthedocs.io/en/latest/

FPGAs have a different IMO bigger problem. They are hugely inferior in density, clock frequency and power efficiency in comparison to ASICs implementing the same function. That's the price for being able to fully configure the logic as you still have to pay for the interconnect you don't use and the logic allowing to configure the logic gates, as well as the local memory cells holding the gate configurations.

In principal I agree that this kind of solves the problem of being in control of what function is being executed. But I'd rather use a risc-v asic with an open implementation.