AMD, ECC and Purism

Hardware
1

It is not a very fresh post

but Linus says AMD is better and has ECC which must be there (it is needed). I wonder if Purism has considered this issue with ECC.

1 Like
2

Besides the ECC issue, right now we can not use Ryzen, though I would love to, because of the firmware restrictions. The GPU included in the Ryzen SOCs needs a firmware at runtime and right now PureOS does not allow that.

Cheers
nicole

1 Like
3

I do not like using hardware where bits flip on their own. Could something like this be used as a workaround?

Basically, have a microcontroller inject the firmware so that as far as the OS is concerned, the firmware was a part of the SOC.

1 Like
4

So, well, we had this discussion already and I fail to see the point in doing such drastic things. It does not help anything or anyone except to keep the FSF endorsement for the OS. Everything else is just made worse by it. Hardware cost will rise, it is a significant development effort and in the end it does not create any benefit at all: The blob is still a blob and even worse, it gets taken out of the control of $average user since it is hidden in some hardware subsystem. This is neither helping to liberate anything nor does it help to make anything more secure. Quite the contrary is the case. You artificially limit usersā€™ control over the firmware and you also limit the usersā€™ (and OS for that matter) ability to apply additional security features to the firmware - like signing it with your own key or least creating your own checksums etc.

But all that aside, we have been talking about the firmware for the GPU here - or letā€™s take the WiFi firmware as another example. These are no simple SDIO devices, these are PCIe attached or even worse, in the case of the GPU, sit directly on the main CPU/SOC - either same silicon die or at least the same package. In the case of the GPU as part of the SOC I do not see a chance how an external additional microcontroller should be able to access that before the main SOC kicks in and takes ownership of the interface? But even for the WiFi card example, we are talking about PCIe here. So such a microcontroler would need to cut the PCIe pins from the main SOC, take control of the WiFi cardā€™s PCIe interface as PCIe master, inject the firmware into the card and then let go of the interface and hand it back to the main SOC. This is not totally impossible, luckily there is PCIe hotplug. But this means to implement a pretty complex subsystem in hardware, a microcontroller that can talk PCIe etc. This is not something light weight you can do with some Arduino, we are talking about pretty serious SOCs here. And even if you would do that this would then end up in a system where only a limited number of WiFi card types can be supported since the controller then needs to store and match the card to a firmware in its storage, which again limits userā€™s freedoms in choosing hardware, they can not use any card they like, just the few that may or may not be supported.
And still all this does not address how firmware should get updated? If we accept these blobs in some form, be it also with painting them as ā€œhardwareā€, it is no good idea at all to not considering updates. Even if we paint it as hardware it is still software and has bugs. Bugs that can also have severe security implications which often get addressed by firmware upgrades.

So in very short words: No, an external microcontroller can not be a solution.

Cheers
nicole

3 Likes
5

Exactly this. Other notable people say the same regarding Coreboot microcode: https://lists.gnu.org/archive/html/libreplanet-discuss/2022-01/msg00019.html.

6

While I in general agree to the sentiment, but microcode is starting to get touchy :wink:

So in general speaking a kind of red line is where the binary actually gets executed. Does it get executed by some MCU on some peripheral? Or does it get executed by the main CPU that is also running the OS? The latter for me is pretty much unacceptable since this can have severe security implications. Some $mystery code could do anything, in general I can not review and audit it (of course to some extend one could by disassembling etc.). So we do not want mystery code running on the main CPU - even if separated, containered, compartementalized or whatever - it is a security risk as soon as it touches the main CPU.

For stuff like a WiFi card etc. this is not a big deal, there the main CPU is just pushing the data through from the filesystem to the WiFi card (or other peripheral) and is done. Code does not get executed on the main CPU, all shiny.

But microcode? While it does executed in itself on the main CPU it can have severe consequences for everything else that gets executed on that CPU. So here my red line becomes pretty blurry already. For this microcode we need to trust CPU manufacturers that it does not compromise the system and that it is 100% definitely authentic and can not be tempered with. I have not looked much into this yet, if this can be assured.

But yes, also microcode updates can be very much necessary! And so far we have been putting these into Coreboot updates instead of the OS, because we also can not ship these with PureOS without loosing the FSF endorsement.

Cheers
nicole

1 Like
7

Does this mean, people with non-Librem hardware using PureOS will not receive the microcode updates? Does this mean, people with Librem and alternative operating systems can have two (conflicting?) versions of the microcode at the same time?

8

Errm, let me parse that :slight_smile:

  • PureOS on non-Purism hardware: Yes, no microcode updates.
  • Purism hardware and other OSes: Well, as far as I understood the microcode update mechanism, this is a one way street, i.e. an OS microcode update mechanism will only upgrade not downgrade. So you will not create a conflict but the OS may have a newer one and upload this or Coreboot may have a newer one and then the OS does nothing.

That the BIOS, in this case Coreboot, installing some version of the microcode is pretty normal, so this case must be handled gracefully anyway. But the case for PureOS on non Purism hardware is a bit annoying indeed since there will be no microcode upgrades unless the BIOS thatā€™s running on it gets upgraded.

Cheers
nicole

2 Likes