It's not bad at all. Long story short, this feature prevented people stealing your ram stick off of your machine, super-freezing it and quickly moving it to their machine before the charge runs out and read off whatever bits are still left intact.
It prevented it by having a hardware module on the CPU's memory controller that AES encrypts the contents you are sending to DRAM, and decrypts it before reading it back to the CPUs memory structures. All with hardware keys completely invisible to software (and one that is basically impossible to manipulate physically).
And you need to be able to do it multiple times for the bits of memory that you want to snoop on, to be the bits that survive the transfer.
> To be fair to AMD, there is no clear indication that the company ever publicly advertised TSME as a consumer Ryzen feature.
A feature that was possibly accidentally enabled on consumer chips is now being disabled. I would guess that the number of owners of consumer chips who also relied on them for encryption is exceedingly small.
The primary concern persists. The manufacturer has an exceptional amount of control of the state of your CPU most of which you cannot change and an unknown chunk of which you cannot even see. We are sort of playing in a fools paradise.
How can manufacturers simultaneously have exceptional control over flags and not enough control to know what flags are enabled on their shipping products?
AMD, historically, has taken a "we don't test enterprise features on consumer SKUs, but we don't fuse them off if you really want to qualify it or let them try it" approach to e.g. ECC on consumer chips with Zen.
So it's quite possible they were doing the same with TSME, and either made a rude marketing decision that the people using it on consumer chips would probably pay for PRO chips if they were prevented from doing so, or kept getting people attempting to RMA the chips for a feature they never said worked on them not working, or there's some systemic flaw in the consumer chip's implementation that they didn't feel like trying to qualify fixing versus just killing the not-guaranteed support.
Hard to guess without more data than just them going silent about it.
They always had control. Awareness is a different thing. You could just as well ask "if you've written every line of code, why did you write that bug?".
I'm trying to progress the discussion past "we don't know if it was intentional". We know it was intentional. What was the intention of having it on before and what is the intention of turning it off?
AMD has limited control over what motherboard manufacturers do. And there have been plenty of examples demonstrating motherboard vendors don't fully understand what they are doing. Stuff like shipping builds with example/placeholder keys, ridiculous voltage settings which destroy the cpu.
Even if motherboard vendors don't have full control to configure to freely change every flag, they probably have access to some kind of debug/development firmware which has a lot more features enabled than what you would have in consumer builds.
> A feature that was possibly accidentally enabled on consumer chips is now being disabled.
Bro what are you smoking? The highly paid and experienced engineers designing these chips could have "possibly enabled" the feature on consumer chips.
The chips were designed with the feature as it is cheaper to do everything right from the get go and disable functionality rather than design a less capable chip then tack on the feature afterwards, just as the consumer versions of Windows are the server versions with functionality removed.
Market segmentation.
How does market segmentation work if you refuse to clarify which chips have the feature and which chips don't?
I would also like to know. Surely some people here have at least second-hand knowledge, and silence can sometimes be deafening.
It's not bad at all. Long story short, this feature prevented people stealing your ram stick off of your machine, super-freezing it and quickly moving it to their machine before the charge runs out and read off whatever bits are still left intact.
It prevented it by having a hardware module on the CPU's memory controller that AES encrypts the contents you are sending to DRAM, and decrypts it before reading it back to the CPUs memory structures. All with hardware keys completely invisible to software (and one that is basically impossible to manipulate physically).
And you need to be able to do it multiple times for the bits of memory that you want to snoop on, to be the bits that survive the transfer.
> To be fair to AMD, there is no clear indication that the company ever publicly advertised TSME as a consumer Ryzen feature.
A feature that was possibly accidentally enabled on consumer chips is now being disabled. I would guess that the number of owners of consumer chips who also relied on them for encryption is exceedingly small.
The primary concern persists. The manufacturer has an exceptional amount of control of the state of your CPU most of which you cannot change and an unknown chunk of which you cannot even see. We are sort of playing in a fools paradise.
How can manufacturers simultaneously have exceptional control over flags and not enough control to know what flags are enabled on their shipping products?
They either have that control or they don't.
AMD, historically, has taken a "we don't test enterprise features on consumer SKUs, but we don't fuse them off if you really want to qualify it or let them try it" approach to e.g. ECC on consumer chips with Zen.
So it's quite possible they were doing the same with TSME, and either made a rude marketing decision that the people using it on consumer chips would probably pay for PRO chips if they were prevented from doing so, or kept getting people attempting to RMA the chips for a feature they never said worked on them not working, or there's some systemic flaw in the consumer chip's implementation that they didn't feel like trying to qualify fixing versus just killing the not-guaranteed support.
Hard to guess without more data than just them going silent about it.
They always had control. Awareness is a different thing. You could just as well ask "if you've written every line of code, why did you write that bug?".
I'm trying to progress the discussion past "we don't know if it was intentional". We know it was intentional. What was the intention of having it on before and what is the intention of turning it off?
You choose every piece of food you eat, how do you not know all the macros?
This analogy holds true if I invented every molecule in my food.
AMD has limited control over what motherboard manufacturers do. And there have been plenty of examples demonstrating motherboard vendors don't fully understand what they are doing. Stuff like shipping builds with example/placeholder keys, ridiculous voltage settings which destroy the cpu. Even if motherboard vendors don't have full control to configure to freely change every flag, they probably have access to some kind of debug/development firmware which has a lot more features enabled than what you would have in consumer builds.
> I would guess that the number of owners of consumer chips who also relied on them for encryption is exceedingly small.
I guarantee you that there's one small company that put 1,000 of these chips in a server room or datacentre though, and they're now completely boned.
In that case I would expect them to try and work something out with AMD directly instead of building a company on undocumented features.
Just dont upgrade the Mainboard firmware then
To be fair same can't be said of ECC, even though ECC should be basic feature out of the box.
> A feature that was possibly accidentally enabled on consumer chips is now being disabled.
Bro what are you smoking? The highly paid and experienced engineers designing these chips could have "possibly enabled" the feature on consumer chips.
The chips were designed with the feature as it is cheaper to do everything right from the get go and disable functionality rather than design a less capable chip then tack on the feature afterwards, just as the consumer versions of Windows are the server versions with functionality removed.