> TSME isn't a critical security feature for most consumer desktops, as it protects against attacks where the attacker needs physical access to the device.
If you think it's hard to gain physical access to a consumer desktop, you're out of touch. Most desktops aren't locked inside a datacenter. Memory encryption is a valuable desktop (and laptop) security feature.
So my PC runs 5% slower because someone could break into my house to get physical access to decrypt memory? OK sure, but not my top concern, and a bad tradeoff for the lost performance. And not only fair, but completely accurate to describe TSME as non-critical for *most* consumer desktops. I'd go as far as to say useless and counter-productive for most, but not all, consumer desktops.
If it's not your top concern, you're probably a government employee with full security clearance and the "consumer desktop" doubles as a pirated game rig, top secret NAS and Twitter battle box.
I think it's more a reference to Spectre and Meltdown and Rowhammer and a bazillion other hold-my-beer attacks that have never, ever been used in the wild but that everyone pays the price for by having their CPUs slowed down by the countermeasures. Applying Unicorn Repellant is fine when there's no cost, but it definitely has a cost in these cases.
Yeah if you’re worried about someone getting physical access to your PC for information you should probably be more worried about someone beating that information out of you first.
I'm a little puzzled by the uproar given that all the oneline chatter seems to suggest nobody is using this. If this was AVX512 or something I could understand the give it back reaction...
I think it's more the principle. CPU firmware upgrades are not supposed be used for things like this, and if it became normal to use them for removing features, it would just lead to people not updating the firmware at all, and that's not a good scenario for anyone.
Physical hardware products shouldn't lose features after launch. If this was a "mistaken" feature which they suggested it was they should have disabled it on future chips.
A lot of this has to do with segmenting the market into high-end and low-end products.
When they were the underdog to Intel, they gave away lots of premium features to beat Intel.
Since they got more popular, AMD has been taking away features, or not upgrading old tech, from their desktop/gaming CPUs: Their DDR5 interface is gimped, being slower than Intel now, and still limited to dual channel. Their chipset link is still PCIe 4x4 the same as two generations ago.
If you want these features now, you need a server product.
None of that is a good rationale for patching the firmware to retroactively remove things from devices that were sold years ago. It's an abuse of a mechanism that's ostensibly meant for security fixes and maybe perf improvements, which is a dangerous game because it incentivizes people to just not update the firmware at all, which is a worse scenario for both parties than just resolving to not include the feature in CPUs going forward if it's such a huge loss to include it.
Judging by the Reddit threads I saw, A LOT of people were upset even though it was clear that they had not idea what the feature actually provided beyond “encryption”. I’d guess that the majority assumed that the change would result in them basically having to “encryption” in affected AMD devices any more in some vague general sense.
Full title: AMD will reinstate memory encryption on Ryzen 9000 CPUs through a BIOS update in July — TSME is coming back after 'valuable community feedback'
Thought there were cases where other devices could have direct access to RAM (e.g. DMA, PCIe controllers outside the CPU, etc.). Wonder how that works in conjunction.
There are many ways it can work depending on the cpu:
1. No dma, instead you use bounce buffers and the cpu manually encrypts and decrypts on behalf of the pcie
2. The IOMMU sets certain pages as unencrypted and ensures the pcie only accesses those pages and that part of ram alone is now not encrypted.
3. Newer pcie devices use the TDISP(handshake) and IDE(aes gcm hardware module related stuff) protocols to do encrypted communication with the CPUs PCIe root hub, where this functionality is called TIO i.e trusted io on amd and TX connect on intel. As far as nvidia GPUs go which is where I have used this, H100 onwards have the feature. Only server xeons and turins etc support this feature on the cpu side. I think some server SSDs do too. Here you get full encryption full DMA at full bandwidth.
They’ve been doing a bunch of stuff in agesa updates regarding memory stability lately, and also recently broke and fixed setting manual speed on DDR5 memory with ECC enabled (basically any setting higher or lower than 5200mhz or something was ignored).
I wonder if this was also something they just accidentally broke, or if it was an incompetent attempt at larger segmentation.
> and also recently broke and fixed setting manual speed on DDR5 memory with ECC enabled (basically any setting higher or lower than 5200mhz or something was ignored).
Do you know when this was fixed? I recently updated my B650D4U and ended up stuck at 5200MHz instead of 5600MHz. Asrock Rack don't seem to take every update, but I have had luck getting beta releases in the past when I've asked about specific versions.
For Asrock, it should be fixed in any bios with 1.3.0.1b
Looking at Asrock consumer motherboards, it’s been rolled out to some but not all yet. The AGESA for that Asrock rack board looks way behind, so I’d definitely make a request to them to update since the squeaky wheel gets the grease if it’s going to at all.
> I wonder if this was also something they just accidentally broke
Their statement suggests it was a calculated decision, reversed after public backlash. I greatly appreciate they listened to user feedback, but they shouldn't have done it secretly to begin with.
> Based on valuable community feedback, we will reinstate this option in an upcoming BIOS release in July.
We're talking about a company that five generations into its processor family still hasn't been able to figure out how to have USB work properly and reliably.
AMD Adrenalin, their software that manages things video/GPU features like clip saving, performance settings, game optimizations, update monitoring, performance overlaying, etc - is so fucking bad that if your mouse is set to a refresh rate over 500hz, it is virtually unusable because the mouse cursor takes half a second to respond to inputs. This is running on a card one step down from the flagship, current generation.
Good. Intel's equivalent processors have this feature and BS market segmentation is the kind of thing that AMD was historically against. Even if something wasn't officially supported, they didn't go out of their way to prevent its use.
If you want to strip some features from things we bought after the purchasing, you must ask me and every other customers for consents explicitly, with a reasonable explanation, and before the strip happens. If one of us show no consent, you cannot do that.
-------------
See the github issue [1]. @benkilpatrick found out the problem in April. There was absolutely no consent asking information transparency at all. There was inefficient to no information even for people willing to spend THEIR OWN TIME to solve the problem. After about two months of back and forth with motherboard manufacturer, @benkilpatrick found out the problem stems from some components inside the bios, and the components came from AMD. Another ~three weeks passed and no problem resolution at all. It was after things blow up AMD PR came out and said something about "valuable feedback".
Wait, what if there's no enough pushback? What if this github issue as well as the problem it raised is ignored by all? Just see this thread, that thread [2] and whatnot. Is your customers going to screw themselves and being stripped silently for being your customers and believing that new bios will solve their problems without causing shenanigans?
-------------
I won't upgrade bios without future third-party bios integrity checks showing the problem is solved properly.
> TSME isn't a critical security feature for most consumer desktops, as it protects against attacks where the attacker needs physical access to the device.
If you think it's hard to gain physical access to a consumer desktop, you're out of touch. Most desktops aren't locked inside a datacenter. Memory encryption is a valuable desktop (and laptop) security feature.
So my PC runs 5% slower because someone could break into my house to get physical access to decrypt memory? OK sure, but not my top concern, and a bad tradeoff for the lost performance. And not only fair, but completely accurate to describe TSME as non-critical for *most* consumer desktops. I'd go as far as to say useless and counter-productive for most, but not all, consumer desktops.
So you turn it off by default in BIOS and allow those that feel it's useful to them to enable it, and you solve for both sides of the problem.
If it's not your top concern, you're probably a government employee with full security clearance and the "consumer desktop" doubles as a pirated game rig, top secret NAS and Twitter battle box.
Does it run slower? I'd expect dedicated hardware to do that encryption/decryption, in which case there should be no difference.
I think it's more a reference to Spectre and Meltdown and Rowhammer and a bazillion other hold-my-beer attacks that have never, ever been used in the wild but that everyone pays the price for by having their CPUs slowed down by the countermeasures. Applying Unicorn Repellant is fine when there's no cost, but it definitely has a cost in these cases.
How can you be so sure they have never been used in the wild? Surely not all uses of them get reported...
If the bad guys have physical access to my consumer desktop, I'm already well and truly fucked.
The last few companies have all had desktops in datacenters with the local PC just a virtual terminal.
> as it protects against attacks where the attacker needs physical access to the device.
Doesn't it also protect against rowhammer-like attacks?
You'd need physical access while it is running as the target is using it.
When the threat model is physical security, henchmen are also a consideration.
Yeah if you’re worried about someone getting physical access to your PC for information you should probably be more worried about someone beating that information out of you first.
People don’t like things being taken away, even if I don’t think many people are actually using this feature.
I don’t even think its exposed in most BIOS’s
And it does reduce memory speed by about 0.5-1%.
I'm a little puzzled by the uproar given that all the oneline chatter seems to suggest nobody is using this. If this was AVX512 or something I could understand the give it back reaction...
I think it's more the principle. CPU firmware upgrades are not supposed be used for things like this, and if it became normal to use them for removing features, it would just lead to people not updating the firmware at all, and that's not a good scenario for anyone.
Physical hardware products shouldn't lose features after launch. If this was a "mistaken" feature which they suggested it was they should have disabled it on future chips.
A lot of this has to do with segmenting the market into high-end and low-end products.
When they were the underdog to Intel, they gave away lots of premium features to beat Intel.
Since they got more popular, AMD has been taking away features, or not upgrading old tech, from their desktop/gaming CPUs: Their DDR5 interface is gimped, being slower than Intel now, and still limited to dual channel. Their chipset link is still PCIe 4x4 the same as two generations ago.
If you want these features now, you need a server product.
None of that is a good rationale for patching the firmware to retroactively remove things from devices that were sold years ago. It's an abuse of a mechanism that's ostensibly meant for security fixes and maybe perf improvements, which is a dangerous game because it incentivizes people to just not update the firmware at all, which is a worse scenario for both parties than just resolving to not include the feature in CPUs going forward if it's such a huge loss to include it.
Judging by the Reddit threads I saw, A LOT of people were upset even though it was clear that they had not idea what the feature actually provided beyond “encryption”. I’d guess that the majority assumed that the change would result in them basically having to “encryption” in affected AMD devices any more in some vague general sense.
Exactly. Thus far I've seen 1 person use it...and they seemed to believe it provides rowhammer benefit...so somewhat tangential
Full title: AMD will reinstate memory encryption on Ryzen 9000 CPUs through a BIOS update in July — TSME is coming back after 'valuable community feedback'
Thought there were cases where other devices could have direct access to RAM (e.g. DMA, PCIe controllers outside the CPU, etc.). Wonder how that works in conjunction.
The encryption/decryption is done in the memory controller so it doesn't matter where the access is coming from.
There are many ways it can work depending on the cpu:
1. No dma, instead you use bounce buffers and the cpu manually encrypts and decrypts on behalf of the pcie
2. The IOMMU sets certain pages as unencrypted and ensures the pcie only accesses those pages and that part of ram alone is now not encrypted.
3. Newer pcie devices use the TDISP(handshake) and IDE(aes gcm hardware module related stuff) protocols to do encrypted communication with the CPUs PCIe root hub, where this functionality is called TIO i.e trusted io on amd and TX connect on intel. As far as nvidia GPUs go which is where I have used this, H100 onwards have the feature. Only server xeons and turins etc support this feature on the cpu side. I think some server SSDs do too. Here you get full encryption full DMA at full bandwidth.
They’ve been doing a bunch of stuff in agesa updates regarding memory stability lately, and also recently broke and fixed setting manual speed on DDR5 memory with ECC enabled (basically any setting higher or lower than 5200mhz or something was ignored).
I wonder if this was also something they just accidentally broke, or if it was an incompetent attempt at larger segmentation.
> and also recently broke and fixed setting manual speed on DDR5 memory with ECC enabled (basically any setting higher or lower than 5200mhz or something was ignored).
Do you know when this was fixed? I recently updated my B650D4U and ended up stuck at 5200MHz instead of 5600MHz. Asrock Rack don't seem to take every update, but I have had luck getting beta releases in the past when I've asked about specific versions.
For Asrock, it should be fixed in any bios with 1.3.0.1b
Looking at Asrock consumer motherboards, it’s been rolled out to some but not all yet. The AGESA for that Asrock rack board looks way behind, so I’d definitely make a request to them to update since the squeaky wheel gets the grease if it’s going to at all.
> I wonder if this was also something they just accidentally broke
Their statement suggests it was a calculated decision, reversed after public backlash. I greatly appreciate they listened to user feedback, but they shouldn't have done it secretly to begin with.
> Based on valuable community feedback, we will reinstate this option in an upcoming BIOS release in July.
We're talking about a company that five generations into its processor family still hasn't been able to figure out how to have USB work properly and reliably.
AMD Adrenalin, their software that manages things video/GPU features like clip saving, performance settings, game optimizations, update monitoring, performance overlaying, etc - is so fucking bad that if your mouse is set to a refresh rate over 500hz, it is virtually unusable because the mouse cursor takes half a second to respond to inputs. This is running on a card one step down from the flagship, current generation.
Don't even get me started about ROCm on Windows.
Good. Intel's equivalent processors have this feature and BS market segmentation is the kind of thing that AMD was historically against. Even if something wasn't officially supported, they didn't go out of their way to prevent its use.
We paid for your things, AMD.
If you want to strip some features from things we bought after the purchasing, you must ask me and every other customers for consents explicitly, with a reasonable explanation, and before the strip happens. If one of us show no consent, you cannot do that.
-------------
See the github issue [1]. @benkilpatrick found out the problem in April. There was absolutely no consent asking information transparency at all. There was inefficient to no information even for people willing to spend THEIR OWN TIME to solve the problem. After about two months of back and forth with motherboard manufacturer, @benkilpatrick found out the problem stems from some components inside the bios, and the components came from AMD. Another ~three weeks passed and no problem resolution at all. It was after things blow up AMD PR came out and said something about "valuable feedback".
Wait, what if there's no enough pushback? What if this github issue as well as the problem it raised is ignored by all? Just see this thread, that thread [2] and whatnot. Is your customers going to screw themselves and being stripped silently for being your customers and believing that new bios will solve their problems without causing shenanigans?
-------------
I won't upgrade bios without future third-party bios integrity checks showing the problem is solved properly.
[1] https://github.com/AMDESE/AMDSEV/issues/292
[2] https://news.ycombinator.com/item?id=48582320
Discussion on the previous development:
AMD silently removes memory encryption from consumer Ryzen CPUs
https://news.ycombinator.com/item?id=48582320
I wish they could enable use of non-ECC ram on Threadrippers.
I wish we'd stop pretending that non-ECC ram is ok on any platform.
Rust developer: "Ba da Ba Ba Ba"
Sure, as long as your OS is written in Rust (and doesn't use any unsafe)