3 ms·

I don't see a difference between RYF-ness of CPU microcode and SSD firmware. The main practical difference in the context of TFA is that distros typically bundl

I don't see a difference between RYF-ness of CPU microcode and SSD firmware. The main practical difference in the context of TFA is that distros typically bundle CPU microcode but not SSD firmware, hence the question is unlikely to come up in that context for SSD firmware, but that doesn't mean that it's not a problem. Btw, the AMD CPU microcode is fused into the CPU, otherwise it wouldn't boot; there's an additional SRAM area where the microcode update is applied; for details see https://media.ccc.de/v/35c3-9614-inside_the_amd_microcode_rom https://media.ccc.de/v/35c3-9614-inside_the_amd_microcode_ro... To elaborate on your last point, I'd always use software encryption with SSDs, because with the opaque firmware wear-leveling it's essentially impossible to be sure that anything is actually physically deleted from SSDs, and if it isn't physically deleted it can be read by a custom firmware.

mindslight 8y ago
I was referring to AMD's graphics cards. They have a binary firmware blob that basically must be loaded, but the loading itself is done by Free software. I don't see how this is any different from a RYF perspective than if AMD had put another flash chip on the BOM for storing it cold. That is, assuming a competent signature scheme for both. So the card itself doesn't RYF, but it can be used to display the output from a RYF computer. And unfortunately barring a better graphics option based on open firmware, these are the compromises we have to make. RMS recognizes this - I just think the manner in which he framed the compromise is a bit unnuanced and out of date. Rather than finding reasons to ignore least-worst blobs, we should be talking about boundaries between Free/non-free components. SSDs are an interesting case, because the hard drive interface abstraction is so simple and longstanding, we just kind of assume it's a good boundary. But if you want to pop back into abstract Freedom land, imagine what the market would look like if vendors weren't able to market around decommoditizing software features. For example, if the FTL were done by Free software (perhaps on the main CPU), there would be no worries about certain lines of drives getting corrupted due to power failures! (And yes, totally agree about FDE. I actually just changed my router back to being a general purpose Linux box, and it felt quite odd installing that with no FDE).
- the_why_of_y 8y ago
  I'm sorry, no idea how I managed to jump from AMD GPUs to AMD CPUs :-)

mindslight 8y ago

I was referring to AMD's graphics cards. They have a binary firmware blob that basically must be loaded, but the loading itself is done by Free software. I don't see how this is any different from a RYF perspective than if AMD had put another flash chip on the BOM for storing it cold. That is, assuming a competent signature scheme for both. So the card itself doesn't RYF, but it can be used to display the output from a RYF computer. And unfortunately barring a better graphics option based on open firmware, these are the compromises we have to make. RMS recognizes this - I just think the manner in which he framed the compromise is a bit unnuanced and out of date. Rather than finding reasons to ignore least-worst blobs, we should be talking about boundaries between Free/non-free components. SSDs are an interesting case, because the hard drive interface abstraction is so simple and longstanding, we just kind of assume it's a good boundary. But if you want to pop back into abstract Freedom land, imagine what the market would look like if vendors weren't able to market around decommoditizing software features. For example, if the FTL were done by Free software (perhaps on the main CPU), there would be no worries about certain lines of drives getting corrupted due to power failures! (And yes, totally agree about FDE. I actually just changed my router back to being a general purpose Linux box, and it felt quite odd installing that with no FDE).

the_why_of_y 8y ago
I'm sorry, no idea how I managed to jump from AMD GPUs to AMD CPUs :-)