• M0oP0o@mander.xyz
    link
    fedilink
    English
    arrow-up
    6
    ·
    48 minutes ago

    Create the problem, sell the solution situation?

    Or just enshitifcation?

  • NarrativeBear@lemmy.world
    link
    fedilink
    English
    arrow-up
    10
    ·
    1 hour ago

    YSK: This feature was disabled with a pushed firmware update.

    Its true it was “not supported”, but the CPU was/is capable of it.

    The big issue here is did AMD disable it accidentally, or did they do it intentionally. If it was intentional why did they not announce it anywhere in the update notes, or anywhere else?

  • BaraCoded@literature.cafe
    link
    fedilink
    English
    arrow-up
    34
    arrow-down
    1
    ·
    4 hours ago

    It’s funny how every big tech decision these last few years all sound like a shitty James Bond villain step in a shitty world domination plan, with shitty corpo writing.

  • Sir. Haxalot@nord.pub
    link
    fedilink
    English
    arrow-up
    21
    arrow-down
    1
    ·
    4 hours ago

    Hold up, since when did consumer Ryzen CPUs have memory encryption support? I was sure that was always a EPYC exclusive feature.

    • ramble81@lemmy.zip
      link
      fedilink
      English
      arrow-up
      20
      ·
      2 hours ago

      I think that’s the crux of the article. The feature was there on some chips but not supported. A new update now prevents access to the feature.

  • BananaTrifleViolin@piefed.world
    link
    fedilink
    English
    arrow-up
    87
    arrow-down
    1
    ·
    6 hours ago

    The headline is a little misleading: the feature has disappeared from consumer chips but AMD is not responding when asked why. As the article itself says: it’s not clear if this is a deliberate decision, or a bug that has caused this issue.

    The headline implies it was a deliberate action. Maybe it was, but at the moment we don’t really know. But it is good that Toms Hardware is writing about this and drawing attention to this issue. It’s concerning regardless of the reason, and it’s also concerning how cagey AMD is being about addressing this issue.

    • QuadratureSurfer@piefed.social
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 hour ago

      A little more context as to when the engineer declined to continue the discussion:

      Kilpatrick then brought up something especially awkward. He reminded Lendacky of a comment that the engineer had made back in 2020, confirming that a Ryzen 3700X, a consumer CPU, “should support TSME.” In a later 2025 comment in the same discussion, Lendacky again recommended using TSME, while noting that the motherboard BIOS provider had to expose the option. So there it was, AMD’s own engineer, years earlier, acknowledging the feature working on exactly the kind of lower-end chip now stripped of it, proving that Ryzen support was not some fantasy users invented.

      After some more back-and-forth, Kilpatrick asked bluntly whether the flag being set to FALSE on consumer chips was a silicon-level limitation or a firmware policy decision — since one is permanent and the other is potentially reversible. Limonciello’s reply effectively closed the chapter. “My apologies, but I don’t have any more information to share on this topic,” he wrote.

      To be fair to AMD, there is no clear indication that the company ever publicly advertised TSME as a consumer Ryzen feature. AMD has long said that a related memory protection, Secure Memory Encryption (SME), is available only in the Pro and EPYC CPU tiers. SME is OS-managed, using a single key and allowing the OS to selectively encrypt individual memory pages. TSME, by contrast, is firmware-managed, encrypting all RAM with no OS involvement.

      Sounds to me like he had originally wanted to have it enabled for consumer CPUs, but some decision was later made to make this a feature only for higher end chips, even if lower end chips could technically support it. I can’t really blame the engineer for wanting to stop the discussion at this point. He’s most likely not the one making these decisions and the questions would be best asked to someone higher up.

  • Barbecue Cowboy@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    14
    arrow-down
    6
    ·
    4 hours ago

    It feels weird this was even ever a standard consumer feature. I wouldn’t even really expect it on enterprise hardware outside of servers. This feels like stuff you only really need to think about if you’re being directly targeted by a group with resources.

    • raldone01@lemmy.world
      link
      fedilink
      English
      arrow-up
      8
      ·
      2 hours ago

      It seems like it is not a lot of overhead if any at all. Also the hardware design easily accommodates it. So why not if the work is already done?

      • tempest@lemmy.ca
        link
        fedilink
        English
        arrow-up
        8
        ·
        2 hours ago

        There is still some overhead. Enough that if you are doing HPC and running on your own hardware you might want want to disable it.

        I’ve disabled it on epycs for this reason but never touched it on ryzens.

  • unexposedhazard@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    16
    ·
    edit-2
    6 hours ago

    The article isnt very clear on this, but did they actually remove a critical feature from already sold products? Surely they can be sued for that?

    • MalReynolds@slrpnk.net
      link
      fedilink
      English
      arrow-up
      12
      arrow-down
      1
      ·
      5 hours ago

      Eh, it protects against a certain class of attack when the attacker has physical access e.g. reading memory with memory probes while the computer is (still) on to get passwords etc., i.e. sophisticated attackers like customs, FBI. If they have physical access you’re probably hosed anyway, but if you have the presence of mind to shut the machine off (not sleep, hard off if needed) memory encryption becomes irrelevant.

        • Janx@piefed.social
          link
          fedilink
          English
          arrow-up
          8
          ·
          3 hours ago

          Isn’t that attack only viable within minutes of a machine being powered down? That seems like a huge caveat…

        • Passerby6497@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          3 hours ago

          That actually is correct, because if you power your system down ahead of time, this attack is meaningless since there is only a VERY short window where this attack works. From your link:

          Attackers execute cold boot attacks by forcefully and abruptly rebooting a target machine and then booting a pre-installed operating system from a USB flash drive, CD-ROM or over the network.

          If your attacker only has your cold machine that’s been off since well before you hit the checkpoint, they can’t do shit with that attack. At best they can boot the system up to verify your system operates as intended, but you don’t have to provide any of the credentials to finish booting or unlock the TPM to load the key material into memory.