no comments (yet)

sorted by: hot top controversial new old
there doesn't seem to be anything here
42 comments in c/technology@lemmy.world view that post
[–] 81 points 4 months 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.

  • source
  • [–] 38 points 4 months 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?

  • source
  • [–] 136 points 4 months ago (1 child)

    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.

  • source
  • hideshow 1 child comment
  • [–] 46 points 4 months 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.

  • source
  • parent
  • [–] 48 points 4 months ago

    If it's deliberate and not put back, there's also the possibility the government made them remove it and not disclose why. So they can continue to access certain info and back doors and this security was giving them issues.

    The government forced email providers to have a backdoor for them. It's the NSA's PRISM program. Been around since at least 2008.

  • source
  • [–] 23 points 4 months ago* (last edited 4 months ago) (14 children)

    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?

  • source
  • hideshow 14 child comments
  • [–] 75 points 4 months ago (4 children)

    Tom's is trash and should be banned. The original Ars article it mentions is better: https://arstechnica.com/security/2026/06/users-cry-foul-after-amd-stripped-memory-crypto-from-its-consumer-cpus/

    Sounds like it was never really supported, but available. With the new BIOS update it's no longer available.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 32 points 4 months ago (3 children)

    If that's the case, AMD shouldn't have problems saying so. Although it's still a very bad move from their part.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 19 points 4 months ago (8 children)

    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.

  • source
  • parent
  • hideshow 8 child comments
  • [–] 12 points 4 months ago (7 children)

    That is not correct. Data can persist in RAM even when powered off, especially if the sticks are frozen. https://en.wikipedia.org/wiki/Cold_boot_attack

  • source
  • parent
  • hideshow 7 child comments
  • [–] 7 points 4 months ago* (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 5 points 4 months ago

    To add to that, even the original paper written with 1999-2007 era SDRAM/DDR/DDR2 is not optimistic about the scenario of a machine that was already powered down at regular operating temperatures:

    with the fastest exhibiting complete data loss in approximately 2.5 seconds and the slowest taking an average of 35 seconds

    And that only got worse with more advanced RAM, not to mention that they lost almost all of the data far quicker than that with only a couple % of bits surviving that long. For all practical intents and purposes, cold boot against an already-powered-down machine is a myth, the cooling has to be applied while it's on.

  • source
  • parent
  • [–] 13 points 4 months ago (1 child)

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

  • source
  • parent
  • hideshow 1 child comment
  • [–] 5 points 4 months ago

    Isn't that attack only viable within minutes of a machine being powered down?

    Not even, try seconds at most.

    All things considered, a cold boot attack is only remotely feasible if the system is powered on when the attack begins. If it's powered off for any length of time, your memory will have decayed past the point of it being usable for the attack.

  • source
  • parent
  • [–] 6 points 4 months ago (1 child)

    Ah, thanks, I stand corrected. Still a good practice.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 4 months ago

    FYI, the cold boot attack is only viable for a handful of seconds before your memory decays enough for it to be worthless for that attack.

    Powering your system down yourself prevents this. Just make sure your system doesn't have fastboot enabled or hibernates instead of a true power off.

  • source
  • parent
  • load more comments (1 reply)
  • [–] 47 points 4 months ago (1 child)

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

  • source
  • hideshow 1 child comment
  • [–] 22 points 4 months ago (4 children)

    Create the problem, sell the solution situation?

    Or just enshitifcation?

  • source
  • hideshow 4 child comments
  • [–] 5 points 4 months ago (3 children)

    what problem did they create?

  • source
  • parent
  • hideshow 3 child comments
  • [–] 8 points 4 months ago (2 children)

    The lack of memory encryption....

  • source
  • parent
  • hideshow 2 child comments
  • [+] 18 points 4 months ago (1 child)
  • [–] 5 points 4 months ago

    I wonder if this is to reduce their value of being used as server CPUs.

  • source
  • [–] 8 points 4 months ago*

    How's that attempt to get back onto consumers' good side again going for you, AMD?

  • source
  • [–] 16 points 4 months ago (4 children)

    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.

  • source
  • hideshow 4 child comments
  • [–] 10 points 4 months ago (1 child)

    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?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 13 points 4 months 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.

  • source
  • parent
  • [–] 2 points 4 months ago (2 children)

    Is this different than the ddr5's memory encryption?

  • source
  • hideshow 2 child comments
  • [–] 3 points 4 months ago (1 child)

    I don't think DDR5 has any encryption built in? Maybe you're thinking of the error correction controller that's on the module now? Memory with inline encryption is not very common, and as far as I know, not actually very secure if the CPU/TPM isn't the one holding the encryption key.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 4 months ago (2 children)
  • 14 comments in c/technology@lemmy.ml view that post
    [–] 21 points 4 months ago (4 children)

    Maybe Intel isn't the only company burning from within...

  • source
  • hideshow 4 child comments
  • [–] 5 points 4 months ago (3 children)

    AMD also recently dropped Linux support from the Vivado free tier. Although the support they had before was really bad

  • source
  • parent
  • hideshow 3 child comments
  • [–] 4 points 4 months ago (2 children)

    AMDGPU has also had major issues since kernel 6.18 that they (AMD, not the linux kernel team, they know) refuse to acknowledge.

    There might be a Linus rant about that one soon...

  • source
  • parent
  • hideshow 2 child comments
  • [–] 8 points 4 months ago (1 child)

    I didn't know memory was ever encrypted. I mean why would it be?

  • source
  • hideshow 1 child comment
  • [+] 6 points 4 months ago (1 child)
  • [–] 4 points 4 months ago*

    If I had my way, everyone's drives and ram and whatever would be encrypted from top to bottom with extremely strong keys that only the user had access to. Nobody needs to have access to your stuff except you, and it doesnt matter if you are the most law-abiding citizen in the world who does nothing but eat bread and read the news paper every day, your privacy is sanctamount (whether you agree with this or not). Medical records, bank statements, tax records, private journals, etc. are just a few examples of data that mundane people with "nothing to hide" deserve to have protected to the nines.

  • source
  • parent
  • load more comments (-1 replies)
    [–] 5 points 4 months ago

    Who would want memory encryption for the hoi polloi to be quietly removed and what colour hat would you think they might wear.

  • source
  • [–] 5 points 4 months ago (4 children)
  • [–] 10 points 4 months ago (3 children)

    But for real. Technofascists will keep making everything worse until there are consequences. Riot in the streets would certainly send that message. Though there are so many things worth rioting over.

  • source
  • parent
  • hideshow 3 child comments
  • [–] -2 points 4 months ago*
    9 comments in c/privacy@lemmy.dbzer0.com view that post
    [–] 12 points 4 months ago*

    "AMD engineer" in this case is actually "senior principal software engineer", which translates to "management". Who was likely told by the VP over his department to STFU based on what the VP was likely told by their legal dept.

    Context is important.

  • source
  • [–] 9 points 4 months ago* (3 children)

    AMD has been winning big in the enthusiast space since Ryzen started taking off. Recently, they've made a lot of opaque and anti-consumer moves. I guess they've decided to start burning some of that good-will they've been building... Meanwhile, intel seems to be warming up? As the pendulum swings, I suppose.

  • source
  • hideshow 3 child comments
  • [–] 3 points 4 months ago (3 children)

    Am i correct in my understanding that if I've got a Ryzen CPU running Linux, and assuming I've not gotten hit by this beforehand, I'm safe so long as I don't pull newer microcode packages from the repos?

  • source
  • hideshow 3 child comments
  • [–] 4 points 4 months ago (1 child)

    This Ars article is better. https://arstechnica.com/security/2026/06/users-cry-foul-after-amd-stripped-memory-crypto-from-its-consumer-cpus/

    It looks like it's from a BIOS update. I'm not sure if the microcode packages will do it too.

    Do you know if you actually had this enabled and working?

  • source
  • parent
  • hideshow 1 child comment