PureOS: freedom, privacy, and security

Posted Jan 10, 2021 20:50 UTC (Sun) by Wol (subscriber, #4433)
In reply to: PureOS: freedom, privacy, and security by marcH
Parent article: PureOS: freedom, privacy, and security

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.