25 ms·

Non sense. I trust my CPU provider or I wouldn’t have bought this CPU. I would much rather use an updated microcode than one known to be insecure. I wouldn’t ch

Non sense. I trust my CPU provider or I wouldn’t have bought this CPU. I would much rather use an updated microcode than one known to be insecure. I wouldn’t check the microcode anyway and I don’t really trust the people who might more than the company providing my CPU. Sure it might contain code making me vulnerable to a state actor but that’s not a threat profile I care about.

marcodiego 5y ago
If you have enough trust in proprietary software distributors to not care to use software that can't be checked, then you're probably not part of this discussion. I don't check all the software I use myself. But I use open-source software with the peace of mind of someone who knows that the incentives to abuse me are simply not there and the fact that right now that are hundreds of people/bots checking it. > Sure it might contain code making me vulnerable to a state actor but that’s not a threat profile I care about. State actors are not the only threat. Think about arbitrarily disabled features, DRM, programmed obsolescence or simply not allowing anybody to improve/fix it after the device is abandoned by the manufacturer.
- kaba0 5y ago
  > the fact that right now that are hundreds of people/bots checking it. As has been shown plenty of times, “more eyes looking at the code” is a fallacy as those eyes are very much not looking to find security vulnerabilities. Also, the lack of security in userspace GNU/linux codebases is something really worrying, much much more so than hypothetical hardware attack when you can just append to the end of .bashrc from a goddamn npm install and basically do anything you want, including streaming every single keypress?
  - marcodiego 5y ago
    > As has been shown plenty of times, “more eyes looking at the code” is a fallacy as those eyes are very much not looking to find security vulnerabilities. There are also automated scans of a long list of FLOSS. Google runs OSS-Fuzz, you can check LibreOffice to see lots of commits to fix defects detected by OSS-Fuzz, coverity and other static analyzers. Access to the code, at the least allows determined users to more easily find where or why the bug happens. And yes, people do it. > hypothetical hardware attack when you can just append to the end of .bashrc from a goddamn npm install and basically do anything you want, including streaming every single keypress? Yes, this is more serious. But would need a compromise on packagers side and an uninformed (or automated) update on my side. Considering an update with such a vulnerability would affect initially a small fraction of users before being discovered, it is very unlikely that this hypothetical would have a big impact.
    - kaba0 5y ago
      It was just one example, but running everything under the user’s user is just terrible. Also, your automatic checker examples are related to the project’s size and importance, not to FOSS alone. It is very welcome but your average one-person C project that is installed on everyone’s system doesn’t benefit from such tools.
  - fsflover 5y ago
    > As has been shown plenty of times, “more eyes looking at the code” is a fallacy This is debatable: https://en.wikipedia.org/wiki/Comparison_of_open-source_and_closed-source_software#Code_quality https://en.wikipedia.org/wiki/Comparison_of_open-source_and_.... Any links to your argument?
    - kaba0 5y ago
      Your link says they are comparable, with another study claiming better quality for open source software. While I really don’t think that grouping together vastly different softwares based on this one quality is meaningful (is a proprietary CRUD app made in 5 months with an ad-hoc architecture comparable to an open source database with proper planning and domain-expert programmers working on it?), I also didn’t claim that they were worse off, just that more eyes won’t find more/all bugs, because in fact, they don’t actually look for them in the first place. The fact remains, every type of software is ripe for bugs and security measures must be taken so those bugs won’t become exploitable.
      - fsflover 5y ago
        https://www.fsf.org/blogs/community/who-actually-reads-the-code https://www.fsf.org/blogs/community/who-actually-reads-the-c...
fsflover 5y ago
I do not trust my CPU provider. Where do I find an alternative based exclusively on free software?
- nix23 5y ago
  https://www.raptorcs.com/TALOSII/ https://www.raptorcs.com/TALOSII/
  - marcan_42 5y ago
    There is no reason to trust IBM not to include a silicon backdoor in POWER9 more than Intel not to include a silicon or microcode backdoor in their x86 chips. TALOS is a lot freer than most designs, but you still need to trust every manufacturer whose silicon went into that motherboard.
    - nix23 5y ago
      >There is no reason to trust IBM not to include a silicon backdoor Yeah ok now we are in the religion side of things, since you cannot check the silicon...well i stop here, not worth my time. BTW: The power microcode is opensource.
      - marcan_42 5y ago
        You can backdoor silicon just as well as you can backdoor software or microcode. Why do you only care about trusting the latter?
        nix23 5y ago
        >>since you cannot check the silicon... READ. The microcode is opensource..
        marcan_42 5y ago
        The silicon - the rest of the logic that makes the CPU - isn't. There's more to CPUs than microcode. Besides, how can you audit that the open source microcode is what the manufacturer actually put into the CPU? Microcode is usually ROM-based with only runtime patches. Open source microcode does not change the fact that you need to trust the CPU manufacturer not to backdoor your CPU. There is literally no way around that that does not involve using FPGAs and restricting yourself to 100MHz CPUs. By the way, I googled POWER9 microcode and was not able to find any source or reference to it. The source code for the firmware running on various auxiliary cores is open source. However, the CPU cores do contain microcode for executing more complex instructions, and I am not finding any reference to this being open source.
medo-bear 5y ago
why is it nonsense? i think not trusting vendors that dont let you verify their product is quite sensible. note this is not paranoia to think that they are doing something malicious. its just as simple as dont trust strangers
- marcan_42 5y ago
  There is no way to verify silicon. This applies to every single chip. If you are using off the shelf hard cores in silicon, you need to trust the vendor. That's just how it is. It's not practical for end users to take silicon chips into a SEM, delayer them, and verify that the design is what they expect. Verifiability aside, there aren't even any high performance CPUs with fully open RTL/netlists available.
  - medo-bear 5y ago
    > If you are using off the shelf hard cores in silicon, you need to trust the vendor if i dont have options for alternatives, i think its completely rational to use something without trusting it. i would say that this should be a default attitude
    - alexvoda 5y ago
      Sandboxing and fencing off untrusted parts is fine. I find the approach of Librem 5 understandable. However the distinction between blob on chip flash and blob on system storage is nonsensical to me. I would much rather have a sandboxed untrusted part I can update rather than a sandboxed untrusted part that I can not update. Unfortunately I have not seen anyone actually give a reason why the line should be drawn there instead of closed source blobs are not ok period. Doesn't matter where they live. None of us are arguing in favour of blobs.
      - medo-bear 5y ago
        >Unfortunately I have not seen anyone actually give a reason why the line should be drawn there instead of closed source blobs are not ok period this makes it sound like FSF supports these blobs. how i understood the situation is that they tolerate them until an alternative presents itself. this is a valid position to take and does not make them hypocrites/cult/religion etc

marcodiego 5y ago

If you have enough trust in proprietary software distributors to not care to use software that can't be checked, then you're probably not part of this discussion. I don't check all the software I use myself. But I use open-source software with the peace of mind of someone who knows that the incentives to abuse me are simply not there and the fact that right now that are hundreds of people/bots checking it. > Sure it might contain code making me vulnerable to a state actor but that’s not a threat profile I care about. State actors are not the only threat. Think about arbitrarily disabled features, DRM, programmed obsolescence or simply not allowing anybody to improve/fix it after the device is abandoned by the manufacturer.

kaba0 5y ago
> the fact that right now that are hundreds of people/bots checking it. As has been shown plenty of times, “more eyes looking at the code” is a fallacy as those eyes are very much not looking to find security vulnerabilities. Also, the lack of security in userspace GNU/linux codebases is something really worrying, much much more so than hypothetical hardware attack when you can just append to the end of .bashrc from a goddamn npm install and basically do anything you want, including streaming every single keypress?
- marcodiego 5y ago
  > As has been shown plenty of times, “more eyes looking at the code” is a fallacy as those eyes are very much not looking to find security vulnerabilities. There are also automated scans of a long list of FLOSS. Google runs OSS-Fuzz, you can check LibreOffice to see lots of commits to fix defects detected by OSS-Fuzz, coverity and other static analyzers. Access to the code, at the least allows determined users to more easily find where or why the bug happens. And yes, people do it. > hypothetical hardware attack when you can just append to the end of .bashrc from a goddamn npm install and basically do anything you want, including streaming every single keypress? Yes, this is more serious. But would need a compromise on packagers side and an uninformed (or automated) update on my side. Considering an update with such a vulnerability would affect initially a small fraction of users before being discovered, it is very unlikely that this hypothetical would have a big impact.
  - kaba0 5y ago
    It was just one example, but running everything under the user’s user is just terrible. Also, your automatic checker examples are related to the project’s size and importance, not to FOSS alone. It is very welcome but your average one-person C project that is installed on everyone’s system doesn’t benefit from such tools.
- fsflover 5y ago
  > As has been shown plenty of times, “more eyes looking at the code” is a fallacy This is debatable: https://en.wikipedia.org/wiki/Comparison_of_open-source_and_closed-source_software#Code_quality https://en.wikipedia.org/wiki/Comparison_of_open-source_and_.... Any links to your argument?
  - kaba0 5y ago
    Your link says they are comparable, with another study claiming better quality for open source software. While I really don’t think that grouping together vastly different softwares based on this one quality is meaningful (is a proprietary CRUD app made in 5 months with an ad-hoc architecture comparable to an open source database with proper planning and domain-expert programmers working on it?), I also didn’t claim that they were worse off, just that more eyes won’t find more/all bugs, because in fact, they don’t actually look for them in the first place. The fact remains, every type of software is ripe for bugs and security measures must be taken so those bugs won’t become exploitable.
    - fsflover 5y ago
      https://www.fsf.org/blogs/community/who-actually-reads-the-code https://www.fsf.org/blogs/community/who-actually-reads-the-c...

fsflover 5y ago

I do not trust my CPU provider. Where do I find an alternative based exclusively on free software?

nix23 5y ago
https://www.raptorcs.com/TALOSII/ https://www.raptorcs.com/TALOSII/
- marcan_42 5y ago
  There is no reason to trust IBM not to include a silicon backdoor in POWER9 more than Intel not to include a silicon or microcode backdoor in their x86 chips. TALOS is a lot freer than most designs, but you still need to trust every manufacturer whose silicon went into that motherboard.
  - nix23 5y ago
    >There is no reason to trust IBM not to include a silicon backdoor Yeah ok now we are in the religion side of things, since you cannot check the silicon...well i stop here, not worth my time. BTW: The power microcode is opensource.
    - marcan_42 5y ago
      You can backdoor silicon just as well as you can backdoor software or microcode. Why do you only care about trusting the latter?
      - nix23 5y ago
        >>since you cannot check the silicon... READ. The microcode is opensource..
        marcan_42 5y ago
        The silicon - the rest of the logic that makes the CPU - isn't. There's more to CPUs than microcode. Besides, how can you audit that the open source microcode is what the manufacturer actually put into the CPU? Microcode is usually ROM-based with only runtime patches. Open source microcode does not change the fact that you need to trust the CPU manufacturer not to backdoor your CPU. There is literally no way around that that does not involve using FPGAs and restricting yourself to 100MHz CPUs. By the way, I googled POWER9 microcode and was not able to find any source or reference to it. The source code for the firmware running on various auxiliary cores is open source. However, the CPU cores do contain microcode for executing more complex instructions, and I am not finding any reference to this being open source.

medo-bear 5y ago

why is it nonsense? i think not trusting vendors that dont let you verify their product is quite sensible. note this is not paranoia to think that they are doing something malicious. its just as simple as dont trust strangers

marcan_42 5y ago
There is no way to verify silicon. This applies to every single chip. If you are using off the shelf hard cores in silicon, you need to trust the vendor. That's just how it is. It's not practical for end users to take silicon chips into a SEM, delayer them, and verify that the design is what they expect. Verifiability aside, there aren't even any high performance CPUs with fully open RTL/netlists available.
- medo-bear 5y ago
  > If you are using off the shelf hard cores in silicon, you need to trust the vendor if i dont have options for alternatives, i think its completely rational to use something without trusting it. i would say that this should be a default attitude
  - alexvoda 5y ago
    Sandboxing and fencing off untrusted parts is fine. I find the approach of Librem 5 understandable. However the distinction between blob on chip flash and blob on system storage is nonsensical to me. I would much rather have a sandboxed untrusted part I can update rather than a sandboxed untrusted part that I can not update. Unfortunately I have not seen anyone actually give a reason why the line should be drawn there instead of closed source blobs are not ok period. Doesn't matter where they live. None of us are arguing in favour of blobs.
    - medo-bear 5y ago
      >Unfortunately I have not seen anyone actually give a reason why the line should be drawn there instead of closed source blobs are not ok period this makes it sound like FSF supports these blobs. how i understood the situation is that they tolerate them until an alternative presents itself. this is a valid position to take and does not make them hypocrites/cult/religion etc