3 ms·

The FSF endorse ThinkPads with two or three chips running secret firmware blobs with full access to system memory via the LPC bus. They also endorse Bluetooth d

The FSF endorse ThinkPads with two or three chips running secret firmware blobs with full access to system memory via the LPC bus. They also endorse Bluetooth dongles running hundreds of kilobytes of proprietary firmware blob (which doesn't count for them because it's in ROM, not /lib/firmware). RYF certification is absolutely meaningless, both from the freedom and security/privacy perspectives. It is actually actively harmful to freedom, as it encourages manufacturers to hide blobs to get through its backdoors (ROM blobs are OK, RAM blobs are not), when doing the opposite is actually more accountable and open, and allows for user-controlled replacement of blobs with free versions in the future. Also, Stallman had personally said he wouldn't give the Novena open hardware laptop RYF certification unless they permanently fused off the GPU, "because otherwise users might be tempted to install the (optional, not distributed with the product or endorsed in any way) GPU blobs". Literally the same product segmentation nonsense we're bashing Intel for here. This was before open drivers became available, which they eventually did. Imagine how wrong the situation would've been if bunnie, the creator of Novena, had actually listened to this; "RYF" certified Novena owners would own crippled machines unable to use 3D acceleration, while the rest would own machines capable of running a 100% libre desktop including 3D acceleration. > Libreboot disagrees with that You do realize that that post is Leah politely saying that RYF sucks and is completely broken, and she's given up on strict compliance, right? FSF policy is indeed that you shouldn't upgrade your microcode (see e.g. endorsing linux-libre, which censors kernel messages telling you about important microcode updates).

fsflover 5y ago
As my link already says, the FSF can and should be improved. However, I think there is a point in separating "hardware" from "software", where the former is not to be updated. If it can be updated by anyone, in any way, it's not hardware.
- marcan_42 5y ago
  If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. Because then users can actually see the code, reverse engineer it, audit it, know they are running the exact version they expect, and potentially replace it with a free one. This concept that "if it's in ROM and cannot be updated it's not software, it's hardware" is asinine, against actual practical freedom for users, and also a net security negative. This whole rhetoric that updatability matters, or that somehow lack of source code means "only the manufacturer can update it" and that somehow "makes things less free for users" needs to stop. Users are still in control of updates, the thing isn't magically phoning home (corner cases of stuff with network access notwithstanding). Having access to the blob is a net positive on all fronts for users. This whole policy keeps trying to use this excuse as a rationale, but the reality is the only thing it achieves is convincing people that they aren't running blobs at all by condoning devices where the blobs aren't evident to users because they're not in their filesystem. This was all brought to its logical extreme of silliness with the Librem 5, which actively engineered an obfuscation mechanism for their RAM training blob to put itself in compliance with RYF, for absolutely no benefit to users: it's still running the same blob as it would've otherwise, and it's still updatable (you can even ignore the entire obfuscation and just flash your own bootloader that does it the normal way).
  - fsflover 5y ago
    > If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. So we both say the same thing with different words. I agree, which is why there is a call to FSF for change. Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion.
    - marcan_42 5y ago
      > So we both say the same thing with different words. I agree, which is why there is a call to FSF for change. I thought you were saying that hardware is whatever "cannot be updated". That's the argument the FSF uses to say ROM firmware is OK because it's not software. I'm saying that's not okay, because updatability is a plus, not a minus, and ROMs are still software. > Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion. The obfuscation in the Librem 5 did absolutely nothing to isolate the proprietary blob in any way, shape, or form. It would always run on a dedicated CPU, from the get-go (and that CPU is part of the RAM controller, so it is a security risk for the entire system either way). They added a third CPU in the loop to load the blob, because somehow touching the blob from the main CPU gives it the digital equivalent of cooties in the FSF's view, but adding this extra step of indirection makes it all OK. And then they put the blob in a separate Flash memory so it wouldn't live in the same flash as the main open firmware, because that somehow helps freedom too? Seriously, that whole story is just utterly stupid no matter which way you look at it.
      - fsflover 5y ago
        > I thought you were saying that hardware is whatever "cannot be updated". Yes, I'm saying that. But if you intentionally prevent users from updating it, then it does not turn software into hardware in my opinion. Do you have any link saying that the blobs are still being executed on the main CPU after the RAM training is finished? Upd: you replied here: https://news.ycombinator.com/item?id=29842166 https://news.ycombinator.com/item?id=29842166.

fsflover 5y ago

As my link already says, the FSF can and should be improved. However, I think there is a point in separating "hardware" from "software", where the former is not to be updated. If it can be updated by anyone, in any way, it's not hardware.

marcan_42 5y ago
If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. Because then users can actually see the code, reverse engineer it, audit it, know they are running the exact version they expect, and potentially replace it with a free one. This concept that "if it's in ROM and cannot be updated it's not software, it's hardware" is asinine, against actual practical freedom for users, and also a net security negative. This whole rhetoric that updatability matters, or that somehow lack of source code means "only the manufacturer can update it" and that somehow "makes things less free for users" needs to stop. Users are still in control of updates, the thing isn't magically phoning home (corner cases of stuff with network access notwithstanding). Having access to the blob is a net positive on all fronts for users. This whole policy keeps trying to use this excuse as a rationale, but the reality is the only thing it achieves is convincing people that they aren't running blobs at all by condoning devices where the blobs aren't evident to users because they're not in their filesystem. This was all brought to its logical extreme of silliness with the Librem 5, which actively engineered an obfuscation mechanism for their RAM training blob to put itself in compliance with RYF, for absolutely no benefit to users: it's still running the same blob as it would've otherwise, and it's still updatable (you can even ignore the entire obfuscation and just flash your own bootloader that does it the normal way).
- fsflover 5y ago
  > If it can be updated by the user, even if the source code is not available, it is freer than if it cannot. So we both say the same thing with different words. I agree, which is why there is a call to FSF for change. Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion.
  - marcan_42 5y ago
    > So we both say the same thing with different words. I agree, which is why there is a call to FSF for change. I thought you were saying that hardware is whatever "cannot be updated". That's the argument the FSF uses to say ROM firmware is OK because it's not software. I'm saying that's not okay, because updatability is a plus, not a minus, and ROMs are still software. > Concerning the Librem 5, if the proprietary blob can be isolated such that it can't access RAM or CPU, it's better for the user and makes the device more free, in my opinion. The obfuscation in the Librem 5 did absolutely nothing to isolate the proprietary blob in any way, shape, or form. It would always run on a dedicated CPU, from the get-go (and that CPU is part of the RAM controller, so it is a security risk for the entire system either way). They added a third CPU in the loop to load the blob, because somehow touching the blob from the main CPU gives it the digital equivalent of cooties in the FSF's view, but adding this extra step of indirection makes it all OK. And then they put the blob in a separate Flash memory so it wouldn't live in the same flash as the main open firmware, because that somehow helps freedom too? Seriously, that whole story is just utterly stupid no matter which way you look at it.
    - fsflover 5y ago
      > I thought you were saying that hardware is whatever "cannot be updated". Yes, I'm saying that. But if you intentionally prevent users from updating it, then it does not turn software into hardware in my opinion. Do you have any link saying that the blobs are still being executed on the main CPU after the RAM training is finished? Upd: you replied here: https://news.ycombinator.com/item?id=29842166 https://news.ycombinator.com/item?id=29842166.