Binary Blobs Continue To Prove Challenging For POWER10 Plus Very Expensive Motherboards

[Developer12]

Absolutely. A deeper certification is in order to accurately describe hardware such as Raptor's. Especially since other companies like Purism strive to obtain the RYF certification on their Intel-based products to better market them as trusted machines (at least that's how I see it), which is as misleading as the RYF name itself.

I'm not sure a new hypothetical certification would fall in the realm of the FSF, though. At which point do they start advocating for "Free Hardware" in addition to Free Software? And is this distinction even relevant anymore? In this sense, your observation is spot-on: for the purposes of user freedom in general, you must have both.

At the end of the day, I care about what the user is able to *do.*

Something I didn't get to, but don't entertain, is arguments like "well, if we just striped the user of their ability to load microcode (or other firmware) it would eliminate their dependence on the firmware/hardware vendor!" No. That's dumb. And it gets even dumber when projects like linux libre remove kernel warnings about Spectre security bugs because fixing them would require microcode patches. In the words of Matthew Garret, that is not in the best interests of the user.

Skip the arbitrary lines of hardware vs software and this obsession with the *software* being pure or the *software* being "free."

What the user can trust, rely on, and do is the ultimate acid test. Everything else is BS.

This is why I'm a HUGE fan of Minecraft Mods. The modding community there has reverse engineered the entire game and produced a set of stable 3rd-party modding APIs that have enabled ENORMOUS, *actual* user freedom. You can do basically anything you want to it.

There are arguments I've linked to in the past that have advocated for a similar stance with all software blobs. They argue for investment in tools like frida, to allow even a novice to trace and understand and modify and replace and bend blobs to one's will. Not strip them out and be left with a broken device and no additional freedoms.

After all, it was by having someone decompile, understand, and document the blob in their ethernet that raptor was able to develop an open-source replacement. A replacement that wouldn't have been possible to provide had the firmware blob not been user-replaceable.

[Viki Ai]

If nobody offers POWER10 with open firmware, that's one more reason to move on to RISC-V, where there's an ecosystem of vendors to pick from.

The thing about RISC-V that has hardware-fetishists like myself excited isn't so much its potential in the main cores (it is a nice efficient and relatively clean ISA, but so are the legacy-stripped versions of ARM V-8 and even OpenPower) but its potential for those up-to-dozens of other 'hidden' CPUs populating the edges of any modern chip more complex than an Atmel SAMD microcontroller. As mentioned by myself and others above, a modern CPU isn't just the well-known cores that run the user code (the OS, and even a hypervisor count as 'user-code' in this context) but all the little specialised CPUs that run the peripherals and buses behind the scenes, usually on custom ISAs that you definitely won't find supported in GCC or LLVM, even if you could reverse-engineer how to write your own blob, and - much more worryingly - almost always operating well outside any security domain.

Being able to replace these custom-ISA CPUs with an appropriately simple RISC-V one (in most cases a RV32I with a handful of proprietary extension instructions to accelerate the critical functionality) means that, from the IP-designer's perspective, they only have to develop+maintain the custom instructions, both in transistors, and as an extension for whatever generic compiler they then get to use, and can leverage the common core for the generic bits of both.

From an OSS perspective, even if those custom instructions are never publicly released (RISC-V only requires that if you want your extra instructions to be part of the standard, and even supplies a bit-field range specifically for instructions that are not intended for public release) it is a lot easier to reverse engineer a few custom instructions on a known standard architecture, and patch GCC/LLVM/etc. to support them, than to do so for a fully-custom ISA. This, of course, may be considered a disadvantage by the IP-design-house, depending on how much the are relying on obfuscation (Bad designer! Bad!) for 'protection' of their IP, but the hope is the pros will outweigh the cons for many of them, and they will find more sociable ways to ensure they profit from their (genuinely hard+smart) work.

Some good news is, this appears to actually be happening, starting with the off-die stuff like storage controllers (eg: Western Digital), so hopefully that trend will eventually infuse its way down on to the die-proper .... Though don't hold you breath while you wait, as that end of the design spectrum is notoriously change-adverse (not an unjustified position in that field!), so while it may yet happen, it won't happen in any hurry!

[phoron]

I think RYF is right. It does as much as it's possible to do.
Yes, hardware can always fuck you up. And any firmware can be fused in or put in ROM instead of loaded through the OS or bootloader. But so what? Hardware could own you with just circuitry if need be.

Just suppose there was another certification requiring no blobs even in ROMs. How could a certification body grant that certification ? Dissabling hardware and putting microscopes to it to reverse engineer hardware is not easy. The manufacturer could publish a design and ship another. Or could ship different hardware to the the certification body than to the public (Hi, VW). No certification would ever be able to tell there weren't blobs in ROMs runnning antifeatures in microcontrollers. The certification would only give a false sense of security.

But certifying the hardware runs with only free software added to it, and the different features work, is feasible. You gather all sources for all software and firmware, compile it yourself and load it on the computer, then you check the different features are working and certificate it.

This can leave hardware backdoors and antifeatures in? Yes, it could. But the only way to avoid them is trusting your hardware provider. Building your own binaries from source may be difficult but scales quite a lot and can be undertaken. Building your own hardware from IP is practically impossible, so here you need to trust or not use any hardware.

RYF means respects your (software) freedom. Respects your rights as user of hardware is something different and it can.t be so easily ensured. Probably not even by a government, let alone the FSF.

It's a little like complaining that RYF doesn't guarantee that you free OS won't have security faults. Well it'll likely will, and someone might use it to install malware on your RYF system, but that's another story. It wouldn't be reasonable to ask RYF to certify that won't happen. Then it's even more difficult for RYF to certify that your hardware vendor won't fool you. It certifies what it can certify.

[Developer12]

I think RYF is right. It does as much as it's possible to do.
Yes, hardware can always fuck you up. And any firmware can be fused in or put in ROM instead of loaded through the OS or bootloader. But so what? Hardware could own you with just circuitry if need be.

Just suppose there was another certification requiring no blobs even in ROMs. How could a certification body grant that certification ? Dissabling hardware and putting microscopes to it to reverse engineer hardware is not easy. The manufacturer could publish a design and ship another. Or could ship different hardware to the the certification body than to the public (Hi, VW). No certification would ever be able to tell there weren't blobs in ROMs runnning antifeatures in microcontrollers. The certification would only give a false sense of security.

But certifying the hardware runs with only free software added to it, and the different features work, is feasible. You gather all sources for all software and firmware, compile it yourself and load it on the computer, then you check the different features are working and certificate it.

This can leave hardware backdoors and antifeatures in? Yes, it could. But the only way to avoid them is trusting your hardware provider. Building your own binaries from source may be difficult but scales quite a lot and can be undertaken. Building your own hardware from IP is practically impossible, so here you need to trust or not use any hardware.

RYF means respects your (software) freedom. Respects your rights as user of hardware is something different and it can.t be so easily ensured. Probably not even by a government, let alone the FSF.

It's a little like complaining that RYF doesn't guarantee that you free OS won't have security faults. Well it'll likely will, and someone might use it to install malware on your RYF system, but that's another story. It wouldn't be reasonable to ask RYF to certify that won't happen. Then it's even more difficult for RYF to certify that your hardware vendor won't fool you. It certifies what it can certify.

This fundamentally isn't a problem solvable with certification. It's a problem that can really only be solved with open hardware, like that worked on by LibreSoC and the wider opencores community. Or, indeed, OpenPOWER in the days of POWER9.

As for the tangles of their policy, see my previous post. It's a lot of wasted effort on messaging that doesn't get anyone anywhere.

[phoron]

Something I didn't get to, but don't entertain, is arguments like "well, if we just striped the user of their ability to load microcode (or other firmware) it would eliminate their dependence on the firmware/hardware vendor!" No. That's dumb. And it gets even dumber when projects like linux libre remove kernel warnings about Spectre security bugs because fixing them would require microcode patches. In the words of Matthew Garret, that is not in the best interests of the user.

I think we've had the argument other times so I'll just drop a line and leave it at it.
If Intel doesn't open their microcode, linux-libre can't tell whether it's really just fixing a bug or fixing it and introducing another one. But never mind. I'm not fond of all that reverse engineering you propose either (for me it's like paying someone for some hardware and then having to do their job for them to have the free firmware or drivers you should have got from the vendor), so we'll just have to agree to disagree.

[Developer12]

I think we've had the argument other times so I'll just drop a line and leave it at it.
If Intel doesn't open their microcode, linux-libre can't tell whether it's really just fixing a bug or fixing it and introducing another one. But never mind. I'm not fond of all that reverse engineering you propose either (for me it's like paying someone for some hardware and then having to do their job for them to have the free firmware or drivers you should have got from the vendor), so we'll just have to agree to disagree.

You can test for Spectre bugs. That's how researchers find them in the first place.

As for this superstition about *new* bugs/backdoors, what makes you think a patch is more likely to insert them than the factory itself? I could just as easily state "they probably REMOVED backdoors that they put in in the factory which now might get discovered due to extra scrutiny."

Reverse engineering is mandatory if you want free replacements for existing blobs. Or to understand what's *actually* in a blob. People should have the capability to do that. The alternative is to build the computer 100% yourself.

[bridgman]

Just suppose there was another certification requiring no blobs even in ROMs. How could a certification body grant that certification ? Dissabling hardware and putting microscopes to it to reverse engineer hardware is not easy. The manufacturer could publish a design and ship another. Or could ship different hardware to the the certification body than to the public (Hi, VW). No certification would ever be able to tell there weren't blobs in ROMs runnning antifeatures in microcontrollers. The certification would only give a false sense of security.

But certifying the hardware runs with only free software added to it, and the different features work, is feasible. You gather all sources for all software and firmware, compile it yourself and load it on the computer, then you check the different features are working and certificate it.

The question is what value that approach adds. Let's say hypothetically you have two vendors, let's call them A and I, with similar products. They both have roughly the same degree of microcoding (arguably A has less) but A runs microcode out of RAM where I runs the equivalent microcode out of ROM.

In that scenario I would get certified while A would not, but you have the same degree of microcode running in both cases. You have even less visibility into the microcode with I, but your certification still promotes I over A.

[deusexmachina]

Hopefully Raptor will be able to team up with some other (strategic) companies to pressure IBM into helping with this. I will 100% buy a Power10 system from RaptorCS if it is blob-free. Which reminds me: can a Power9 system with a modern Radeon card be run without GPU firmware blobs? As I understand is AMD GPU drivers are FOSS, but not all of the blobs are...

[Keats]

Yikes. In the hypothetical scenario where I was willing to pay $3500 for just a motherboard, I wouldn't accept any compromises either.

[phoron]

The question is what value that approach adds. Let's say hypothetically you have two vendors, let's call them A and I, with similar products. They both have roughly the same degree of microcoding (arguably A has less) but A runs microcode out of RAM where I runs the equivalent microcode out of ROM.

In that scenario I would get certified while A would not, but you have the same degree of microcode running in both cases. You have even less visibility into the microcode with I, but your certification still promotes I over A.

It adds the value it can add. A blob drop whenever A wants does not bring any more useful visibility than I secrecy.
And the fact that A pushes an opaque blob out in the public does not mean that it doesn't have one hundred more hidden in ROMs like I does.
The only difference between A and I is that A can add misfeatures later with blob updates and I can't.

You look at it like you know what the vendors are doing, but consumers don't know what the vendors do in their hardware. Yet A ask for them to give opaque code to the hardware instead of bringing transparency by freeing the sources of the blob or at least stop asking the consumer to do their job by providing the blob.

RYF doesn't promote A or I, it promotes F who gives source for all firmware.