7 ms·

> "removes security warnings informing users that they need to update their CPU microcode" If you update your CPU microcode to something that can't be checked,

> "removes security warnings informing users that they need to update their CPU microcode" If you update your CPU microcode to something that can't be checked, you're already sacrificing security. EDIT: But yes, I understand people complaining that FSF rejects proprietary software but is OK with some forms of ROM which in turn may be very similar to "proprietary software you can't change". Well, I never asked their reasons to someone from inside the FSF, so I my knowledge about it can improve. Nevertheless, I can see some points: - AFAIK, the form of accepted code is only for "secondary processors" and can't take over the system or compromise it, - having things in ROM forces manufacturers to maximally simplify it, - having things in ROM forces manufacturers to implement more features in software that can be checked and - having things in ROM forces manufacturers to be extra careful when implementing it. I don't think FSF would consider IME acceptable if it was ROM. But indeed, it would be very good if someone from FSF could better explain it.

seoaeu 5y ago
The question is why proprietary microcode that ships with your CPU is fine, but microcode patches released later are non-free? According to the FSF, you should never apply a vendor's microcode patch and instead you should buy a newer processor from them which will ship with the microcode patch already burned in. You can't even argue that it is a difference of being stored in ROM vs. RAM because the existence of patches means that microcode is upgradeable.
WastingMyTime89 5y ago
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.
- 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
pdpi 5y ago
> If you update your CPU microcode to something that can't be checked, you're already sacrificing security. You're not sacrificing security, you're making a tradeoff. If I update my CPU microcode to something I can't check myself, I'm explicitly choosing to trust my CPU provider, under the assumption that the risk of a microcode-based attack from my CPU provider is smaller than the risk of a cpu bug-based attack by an unknown attacker.
- Qwertious 5y ago
  >You're not sacrificing security, you're making a tradeoff. If you don't trust your CPU provider then you have zero security from them already. Even if the entire design of the CPU is open-source. https://www.bunniestudios.com/blog/?p=5706 https://www.bunniestudios.com/blog/?p=5706
tzs 5y ago
> If you update your CPU microcode to something that can't be checked, you're already sacrificing security. You are already running CPU microcode that can't be checked when you are running Guix on x86. That ship sailed when you decided to use x86.

seoaeu 5y ago

The question is why proprietary microcode that ships with your CPU is fine, but microcode patches released later are non-free? According to the FSF, you should never apply a vendor's microcode patch and instead you should buy a newer processor from them which will ship with the microcode patch already burned in. You can't even argue that it is a difference of being stored in ROM vs. RAM because the existence of patches means that microcode is upgradeable.

WastingMyTime89 5y ago

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.
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

pdpi 5y ago

> If you update your CPU microcode to something that can't be checked, you're already sacrificing security. You're not sacrificing security, you're making a tradeoff. If I update my CPU microcode to something I can't check myself, I'm explicitly choosing to trust my CPU provider, under the assumption that the risk of a microcode-based attack from my CPU provider is smaller than the risk of a cpu bug-based attack by an unknown attacker.

Qwertious 5y ago
>You're not sacrificing security, you're making a tradeoff. If you don't trust your CPU provider then you have zero security from them already. Even if the entire design of the CPU is open-source. https://www.bunniestudios.com/blog/?p=5706 https://www.bunniestudios.com/blog/?p=5706

tzs 5y ago

> If you update your CPU microcode to something that can't be checked, you're already sacrificing security. You are already running CPU microcode that can't be checked when you are running Guix on x86. That ship sailed when you decided to use x86.