PureOS: freedom, privacy, and security

Posted Jan 7, 2021 15:13 UTC (Thu) by brunowolff (guest, #71160)
In reply to: PureOS: freedom, privacy, and security by raof
Parent article: PureOS: freedom, privacy, and security

The RYF approach seems to be that as long as the user has the same ability to update as the vendor, that is OK. I prefer Raptor's approach where they look at which side of the IOMMU the hardware is on. You can generally set things up so that devices with binary blobs can only do DOS attacks against you except for network chips that can directly communicate to others if the IOMMU restricts their access to memory. For example if you use software disk encryption, your disk drives can't steal information from you nor get you to execute desired malware. It can just break things by lying about storing data or returning effectively random garbage. They are encouraging work to replace to replace the firmware for bcm5719s to reduce the ease at which the network chip they use, can be used against you. A couple of people have done a lot of work to get the replacement firmware working, though it isn't considered ready for production yet.

PureOS: freedom, privacy, and security

Posted Jan 7, 2021 20:19 UTC (Thu) by cpitrat (subscriber, #116459) [Link] (1 responses)

> your disk drives can't steal information from you nor get you to execute desired malware

If it injects a malware on the fly in a binary it returns, then it can definitely get you to execute malware

PureOS: freedom, privacy, and security

Posted Jan 7, 2021 20:57 UTC (Thu) by Jandar (subscriber, #85683) [Link]

>> your disk drives can't steal information from you nor get you to execute desired malware

>If it injects a malware on the fly in a binary it returns, then it can definitely get you to execute malware

The first quote was dependent upon "if you use software disk encryption". I you use encryption one can only inject random garbage.

PureOS: freedom, privacy, and security

Posted Jan 10, 2021 2:13 UTC (Sun) by marcH (subscriber, #57642) [Link] (8 responses)

> > I can see how they got there: without an exception for binary blobs on secondary processors there is no hardware that could get a RYF certification.

Very good point, thanks. Like it or not there are now dozens of "secondary" processors and micro-controllers in every computer and smartphone, all requiring some firmware which is almost never open source. Most pages ranting about "binary blobs" seem surprisingly naive about that.

BTW binary blobs do not automatically make all efforts on the main processor useless, the attack surface matters.

> > Take exactly the same blob and stick it on a ROM chip - so it cannot be upgraded or replaced by a free alternative? That hardware now does Respect Your Freedom™.

Having a ROM chip and not being upgradable are two different things. In fact it's common to require both because booting needs to start somewhere.

> The RYF approach seems to be that as long as the user has the same ability to update as the vendor, that is OK.

Could you elaborate? I don't get this sorry.

> I prefer Raptor's approach where they look at which side of the IOMMU the hardware is on.

Very interesting, thanks. As a coincidence: https://lwn.net/Articles/841916/ "Restricted DMA"

PureOS: freedom, privacy, and security

Posted Jan 10, 2021 9:36 UTC (Sun) by Wol (subscriber, #4433) [Link] (7 responses)

> > > Take exactly the same blob and stick it on a ROM chip - so it cannot be upgraded or replaced by a free alternative? That hardware now does Respect Your Freedom™.

> Having a ROM chip and not being upgradable are two different things. In fact it's common to require both because booting needs to start somewhere.

And are mutually incompatible, unless the ROM is actually user-replaceable or an EPROM. The whole point of a ROM is it cannot be (re)written. It's like an old-fashioned write-once CD ...

> > The RYF approach seems to be that as long as the user has the same ability to update as the vendor, that is OK.

> Could you elaborate? I don't get this sorry.

The vendor should not retain powers that the user does not have. If BOTH the vendor and user can update the device, that's okay. If NEITHER the vendor NOR the user can update the device, that's fine.

But if the vendor CAN update the device, and the user CANNOT update the device, then it's clearly not the user's device ...

Cheers,
Wol

PureOS: freedom, privacy, and security

Posted Jan 10, 2021 20:03 UTC (Sun) by marcH (subscriber, #57642) [Link] (6 responses)

> > Having a ROM chip and not being upgradable are two different things. In fact it's common to require both because booting needs to start somewhere.

> And are mutually incompatible, unless the ROM is actually user-replaceable or an EPROM. The whole point of a ROM is it cannot be (re)written. It's like an old-fashioned write-once CD

You're missing the point. Code in the ROM can check for later version and run that instead of itself.

PureOS: freedom, privacy, and security

Posted Jan 10, 2021 20:50 UTC (Sun) by Wol (subscriber, #4433) [Link] (5 responses)

Hmmm ... yes.

But how usual is that? Take a motherboard - the BIOS is usually in EEPROM, not ROM. Modern mobos often have a dual bios and the first one *could* be ROM ...

Or a video card - a ROM who's purpose it is to load the blob?

You're right, but I don't think it's *economically* feasible ... manufacturers wouldn't do it except in prototypes.

Cheers,
Wol

PureOS: freedom, privacy, and security

Posted Jan 10, 2021 21:01 UTC (Sun) by mpr22 (subscriber, #60784) [Link]

The Amiga 1000's original boot ROM, as released in the hardware sold to the general public, had one job: load Kickstart.

Loading Workbench (or booter applications) was Kickstart's job.

PureOS: freedom, privacy, and security

Posted Jan 10, 2021 22:07 UTC (Sun) by farnz (subscriber, #17727) [Link] (1 responses)

Note that in your example, the processor has a ROM embedded in it, whose job is to bring up external buses it needs to access the motherboard EEPROM (or Flash) and then load code from there. This is a ROM that RYF is fine with - it can't be changed after leaving the factory, because it is literally part of the processor's hard wiring, used to access the second-stage firmware from external memory.

This is very common in modern CPUs; now that memories tend to be complex protocols, not simple asynchronous busses like the ROM and DRAM of the 1980s, you need some form of programmable logic to bring up and sequence the bus in the right ways to get code to transfer across into the processor caches, and you might as well implement that logic as code for the processor that can be built into the CPU in a small and simple ROM.

PureOS: freedom, privacy, and security

Posted Jan 11, 2021 1:24 UTC (Mon) by Wol (subscriber, #4433) [Link]

Yeah.

But to go back to the post that started this, it sounded like the ROM was supposed to be upgradeable ... which is not practical/possible.

Using the ROM to simply pull in the real code - can that code be modified by the user (which Respects Your Freedom), or is it code that is signed or otherwise unmodifiable by the user, in which case it doesn't Respect Your Freedom.

Cheers,
Wol

PureOS: freedom, privacy, and security

Posted Jan 11, 2021 2:37 UTC (Mon) by pabs (subscriber, #43278) [Link]

CPU microcode does that. Also things like WiFi and GSM firmware often have a lot of the code in ROM and then updates go into RAM and there is not enough RAM to be able to replace all of the ROM code.

PureOS: freedom, privacy, and security

Posted Jan 11, 2021 10:18 UTC (Mon) by marcH (subscriber, #57642) [Link]

> Hmmm ... yes. But how usual is that?

The original question is how do the various "no binary blob" policies handle real-world hence complex cases like this (not just this one). The naive ones may backfire.