I was in the non-profit shop of a local charity. They accept donations of used computers then resell them to the public. The profit goes to charity. I asked for their oldest machine. It had an AMD chip from the 16h family. Thus, a spychip.

So their oldest machine was still too new for me. I asked why don’t you have anything older? They said the general public would not accept anything older, and so the shop also does not accept anything older. When machines are rejected, they go to a factory that destroys them and recovers the raw metals.

It’s sad to see that pre-spychip machines are being destroyed and that even 2nd-hand customers are being limited to anti-consumer spychip hardware.

  • evenwichtOP
    link
    fedilink
    arrow-up
    2
    arrow-down
    9
    ·
    1 day ago

    “Meltdown affects Intel x86 microprocessors, IBM Power microprocessors,[1] and some ARM-based microprocessors”

    I don’t see AMD on that list. Do you?

    “At the time of disclosure (2018), this included all devices running any but the most recent and patched versions of iOS,[5] Linux,[6][7] macOS,[5] or Windows.”

    So this vuln can be fixed by patching OS kernels, and your reaction is to switch to a CPU that runs embedded closed-source software controlled by a corporate third party who decides what is authorized to execute on your own system? You can fix the problem with or without being nannied. I’ll take the latter.

    Spectre affected “All pre-2019 microprocessors”. So no, the spy chip did not protect you. Intel injected the spychip from 2008 forward and AMD did it from 2013 forward.

    More generally, it’s not smart infosec to introduce extra complexity. It’s profoundly naive to stick a big attack surface in the core of your CPU. I think it’s quite well established that vulns exploit defects, and defects are proportional to complexity. Signing up for a closed source blob in the core of your processor is adding complexity that’s far from wise.

    The /chase the shiny/ mentality (of “latest is greatest!”) neglects the fact that you sign up for the worst kind of vulns – the unknown variety. With old gear the vulns are more of the known variety, which you have a fighting chance of controlling for.

    • rockSlayer@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      13
      arrow-down
      1
      ·
      1 day ago

      I don’t see AMD on that list. Do you?

      Lashing out at me was unnecessary. I was pointing out that there are 2 catastrophic vulnerabilities that are guaranteed to be present in every chip that meets your criteria.

      I’m not defending the IME or the PSP. The most generous thing I can say about them is that they are unnecessary. I’m pointing out that the chips that you want to use have been unsupported for so long that they have catastrophic vulnerabilities that have never even been attempted to be patched. There are more catastrophic vulnerabilities than just Spectre and Meltdown.

      • evenwichtOP
        link
        fedilink
        arrow-up
        3
        arrow-down
        9
        ·
        15 hours ago

        Lashing out at me was unnecessary.

        It was an attack on your bullshit. Not on you personally.

        I was pointing out that there are 2 catastrophic vulnerabilities that are guaranteed to be present in every chip that meets your criteria.

        And I was pointing out that you are wrong.

        I’m pointing out that the chips that you want to use have been unsupported for so long that they have catastrophic vulnerabilities that have never even been attempted to be patched.

        You are advocating for chips that are /more/ vulnerable, not less. You are advocating for chips with a much larger attack surface which brings copious unknown vulns. Overall, you are giving poor advice from an infosec standpoint. It is easier to secure a simple known thing than a complex unknown thing.

        There are more catastrophic vulnerabilities than just Spectre and Meltdown.

        I’m listening.

        • rockSlayer@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          7
          arrow-down
          1
          ·
          9 hours ago

          And I was pointing out that you are wrong

          No, you weren’t. You were being pedantic. AMD will have Spectre. Intel will have Spectre and Meltdown. 2 vulnerabilities.

          You are advocating …

          No, I wasn’t. Stop putting words in my mouth. Unless you know how to write microcode, I have serious doubts that you are capable of successfully patching the vulnerabilities on those chips.

          Do whatever you want. I don’t care.

          • evenwichtOP
            link
            fedilink
            arrow-up
            2
            arrow-down
            4
            ·
            edit-2
            8 hours ago

            No, you weren’t. You were being pedantic.

            If you don’t like the facts, what more is there to say? The facts failed to support your claims. If you will not let the facts shape your world view, then it’s on you to go off and find different facts.

            No, I wasn’t. Stop putting words in my mouth.

            Advocating for only running “supported” chips is inherently contempt for old hardware. (But note you said that apparently without knowing about the 15h.org project).

            Unless you know how to write microcode, I have serious doubts that you are capable of successfully patching the vulnerabilities on those chips.

            How are you still failing grasp this? The fix was made. And it was done in the kernel without writing microcode. You’ve been told this already. You did not counter it yet to still failed to absorb it. And now you try recycling defeated arguments. You don’t even have to patch Meltdown on chips unaffected by Meltdown (AMD). The spychip failed to protect from both Meltdown and Spectre.

            Patching is not the only way to control for a vuln. I am not going to give you the whole infosec discipline here in this thread. There are many ways to controlling for a vuln apart from patching. Depending on your threat model and use cases, there may be no need to do any control. The 15h.org project is another kind of control. Air gapping is another. Detecting the malicious code is another.

            • rockSlayer@lemmy.blahaj.zone
              link
              fedilink
              English
              arrow-up
              2
              ·
              edit-2
              8 hours ago

              You act like you’re the only one that understands information security. I took a security class for my computer science degree too. Productive conversation cannot be had when you strut around arrogantly dismissing everyone that disagrees with you.

              The fix was made. And it was done without writing microcode.

              Spectre was a microcode patch. Meltdown was a kernel patch, so in firmware. Only AMD bothered to fix chips that fit within your timeframe. The fix has not been made for the chips you want to use.

              Patching is not the only way to control for a vuln

              You aren’t going to stop branch prediction with clever tricks. These are hardware level flaws. Patching is the only way to completely mitigate these flaws.

              • evenwichtOP
                link
                fedilink
                arrow-up
                1
                arrow-down
                2
                ·
                8 hours ago

                dismissing everyone that disagrees with you.

                What’s being dismissed is irrelevant facts. You continue (for a 3rd time) to still fail to grasp the fact that Meltdown was not found to affect AMD chips. It’s wholly irrelevant.

                Spectre was a kernel patch, so in firmware.

                Those are two different things. There was a firmware patch. And separately there was a kernel mitigation. You don’t need both.

                Only AMD bothered to fix chips that fit within your timeframe. The fix has not been made for the chips you want to use.

                You mean AMD’s f/w patch was not made. Yet you’ve been told about the 15h.org project. If you absorbed that, then citation needed that Coreboot fails to mitigate. In the absence of Coreboot, the os mitigation was implemented in linux. So you’re pushing a bullshit problem.

                • rockSlayer@lemmy.blahaj.zone
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  7 hours ago

                  I’m aware of coreboot. I was not aware that the project managed to increase support to include configurations for all chips that predate IME and PSP. Last I recall when I looked at coreboot, there were chips that they didn’t think could ever be supported, even without nannyware. I wasn’t pushing a bullshit problem, I was raising legitimate concerns for problems that I didn’t know had solutions. If you don’t want people to raise honest, good faith concerns to you then you better be extremely vigilant that you don’t step in shit.