News All AMD Zen CPUs Vulnerable, Might Need to Disable SMT

[Admin]

Newly discovered side-channel attack recovers 4096-bit RSA key on AMD's Zen-based CPUs.

All AMD Zen CPUs Vulnerable, Might Need to Disable SMT : Read more

 

[johnrock2]

Might need to disable SMT to prevent an attack that requires an attacker to first run code on your PC in order to take advantage of the attack vector...

Why? As far as I can tell this is another one of those "you have to be physically present at the PC" attacks or "the user has to be dumb enough to run untrusted software" schemes. Disabling SMT over something like this is like removing the turbo on your car's engine because it's possible that somebody could break into you car and rig it to behave in a way not expected. You don't cripple your equipment to spite the enemy, you fix your security.

It's incredibly narrow sighted to strip out one of CPU technology's greatest efficiency and computational improvements to close a single hard to use attack vector. Instead You put out an advisory for those using such CPUs to process sensitive information so they can make a decision for themselves. Everyone else will get a microcode patch or an os update to fix the issue at a latter date.

I don't get all the fear mongering that crops up around these obscure and hard to pull off attacks. If you had said there's a 5 digit code a webpage can send to my CPU that would allow the page to do whatever it wanted with my machine then yeah I would say something drastic needs to be done, but this attack vector is never really going to be a problem for 99.9999% of people using zen 1/2/3 CPUs.

 

[DingusDog]

Might need to disable SMT to prevent an attack that requires an attacker to first run code on your PC in order to take advantage of the attack vector...

Why? As far as I can tell this is another one of those "you have to be physically present at the PC" attacks or "the user has to be dumb enough to run untrusted software" schemes. Disabling SMT over something like this is like removing the turbo on your car's engine because it's possible that somebody could break into you car and rig it to behave in a way not expected. You don't cripple your equipment to spite the enemy, you fix your security.

It's incredibly narrow sighted to strip out one of CPU technology's greatest efficiency and computational improvements to close a single hard to use attack vector. Instead You put out an advisory for those using such CPUs to process sensitive information so they can make a decision for themselves. Everyone else will get a microcode patch or an os update to fix the issue at a latter date.

I don't get all the fear mongering that crops up around these obscure and hard to pull off attacks. If you had said there's a 5 digit code a webpage can send to my CPU that would allow the page to do whatever it wanted with my machine then yeah I would say something drastic needs to be done, but this attack vector is never really going to be a problem for 99.9999% of people using zen 1/2/3 CPUs.

Hear! Hear!

 

[TJ Hooker]

Might need to disable SMT to prevent an attack that requires an attacker to first run code on your PC in order to take advantage of the attack vector...

Why? As far as I can tell this is another one of those "you have to be physically present at the PC" attacks or "the user has to be dumb enough to run untrusted software" schemes. Disabling SMT over something like this is like removing the turbo on your car's engine because it's possible that somebody could break into you car and rig it to behave in a way not expected. You don't cripple your equipment to spite the enemy, you fix your security.

It's incredibly narrow sighted to strip out one of CPU technology's greatest efficiency and computational improvements to close a single hard to use attack vector. Instead You put out an advisory for those using such CPUs to process sensitive information so they can make a decision for themselves. Everyone else will get a microcode patch or an os update to fix the issue at a latter date.

I don't get all the fear mongering that crops up around these obscure and hard to pull off attacks. If you had said there's a 5 digit code a webpage can send to my CPU that would allow the page to do whatever it wanted with my machine then yeah I would say something drastic needs to be done, but this attack vector is never really going to be a problem for 99.9999% of people using zen 1/2/3 CPUs.

I don't think anyone is suggesting Joe Blow disable SMT on his personal Ryzen computer. The relevant audience for this issue (along with most other side channel attacks, e.g. spectre/meltdown) is more or less cloud users (and hosts), where you're sharing hardware with untrusted parties by design.

 

[hotaru251]

Why? As far as I can tell this is another one of those "you have to be physically present at the PC" attacks or "the user has to be dumb enough to run untrusted software" schemes.

its more for business/public place systems.

as they have many ppl use them and does open risk.


home users rarely ever have to worry about these.

 

[TheThief]

A different mitigation to just disabling SMT might be to just make sure SMT threads are all allocated to the same VPS of a cloud host? That way only code from the same client can be on the threads of the same core.

Most VPSs are two or more threads anyway these days, so it may already be done that way.

 

[Viking2121]

I'll keep my SMT enabled thank ya vary much

 

[digitalgriffin]

AMD recommends software developers employ existing best practices including constant-time algorithms and avoiding secret-dependent control flows where appropriate to help mitigate this potential vulnerability," AMD's mitigation reads.

Constant time algorithm are a rarity, when the data is random and there is conditional branching based upon that data.

For example, even though a typical heap sort runs in O(n*log ( n ) + n), it requires moving of data in memory in arrays. Sometimes you will need to move it as you execute the heapify and then downsift. Sometimes you won't. Thus any memory move on a large array is unpredictable on run time when the data is unpredictable. Then there's the more common tournament sorts. (I prefer heap sorts for specific applications where large blocks of linear memory are available as it makes cache reads and write hits more likely)

 

[digitalgriffin]

On a side note: Questions:

1. Will this delay Zen 4?
2. Could this be a possible solution: Break apart the Execution keys into various small step executions that would be indistinguishable from regular code? Some secure communication channels do this to prevent packet tracing from source to target. They break apart long single packets into smaller randomly sized packets sent along different paths. This way the single source packet doesn't look like the final multiple packets on the receivers end. Obviously this would have to be done on future hardware as to not invoke a performance penalty.
   
   OR
   
   Could you isolate the core that is running RSA from other threads with a forced flush after on the tables. Dedicating a core to an RSA task on modern 6+ core processors shouldn't be an issue. Most are NOT running all their cores full tilt for this kind of work (I would imagine)

 

[digitalgriffin]

its more for business/public place systems.

as they have many ppl use them and does open risk.


home users rarely ever have to worry about these.

Quite correct. Any developer can attack a cloud server this way. If that cloud server host more than one service, you have problems.

I remember talking to a CEO in an elevator when Azure was released and I asked a very pointed question, "Running services on a cloud it great, until you realize the cloud is vulnerable to a common attack using the very same open services you use." He was silent and just gave me a look.

Running your own services might be more costly, but at least you know who's accessing them, and what's running on them.

But bean counters....

 

[svan71]

Well Intel just came out with a vulnerability so .

 

[cfbcfb]

This requires physical access to the device.

So, unless you're running a kiosk and you can't lock it up, not much to worry about.

Academically interesting, not of concern to actual users. Would have been nice if they'd mentioned this. The first news I saw on it the other day mentioned the actual impact.

Clickbait.

 

[mikeebb]

Is this the first SMT attack on AMD? Intel's had many attacks on hyperthreading (its name for SMT). Not sure all of them have been or even can be fixed - there are some inherent issues with running simultaneous threads on the same core. Ordinarily, not a problem. With a determined attacker who has access, problem. Though with the needed level of access, you probably have even bigger problems.

As others have noted: beware publicly accessible computers like kiosks, ATMs, public library computer banks, etc. Also cloud - though I think general practice now is (or should be) to disable SMT on cloud servers for exactly this reason, preventing SMT/hyperthread-based attacks. Ever notice the large number of physical cores, including multiple CPUs, in servers?

I've always been happier, in principle, with lots of physical cores rather than half real cores and half virtual ones. The OS doesn't help when it exposes logical cores without distinguishing between real and SMT, leaving it up to the software developers to figure out which is which when it matters.

 

[RedBear87]

Technically it's not "all" Zen CPUs, a few models like the 3200G and 3500X already incorporate the "fix" by design.

 

[edzieba]

This requires physical access to the device.

False. This attack does not require root privileges, and can be conducted from within a VM. e.g. from p.2 of the paper:

Across VMs, we leak full RSA-4096 keys with only 50 500 traces and less than 18 (n = 10, σx¯ = 3.26) bit errors.
[...]

1. We evaluate our attack in native and cross-VM covert channels, with bandwidths of 2.70 Mbit/s (native) and 0.89 Mbit/s (cross-VM), at error rates of less than 1 %.
2. We show that the SQUIP side-channel leakage is precise enough to recover full RSA-4096 keys with only 50 500 traces, with on average less than 5 (n = 10, σx¯ = 1.28) bit errors across native processes and less than 18 (n = 10, σx¯ = 3.26) bit errors across virtual machines

Due to the lack of need for root to perform this exploit, as long as you can spawn a process on a Zen machine you can attack other processes on the same core, including crossing security boundaries.
If you can spawn an arbitrary number of processes on a non-hypervisor system, you can thus effectively attack any other process on that machine by spawning sufficient threads in order to have at least one assigned to each core.
For VMs where the hypervisor limits which cores VM can spawn threads to, you can only attack processes in VMs that share the same cores.

Note that this does very much apply to desktop machines: any application that can spawn processes (no root required) can perform this attack.

 

[shady28]

Thinking a lot of brand fans failed to read the article.

They were able to steal a 4096 bit RSA encryption key from an OS running on one VM, from another VM.

That's a very serious problem for their server chips.

If I were running a large cloud service, and especially if I were using one, that was running on AMD Zen hardware I'd be very very worried about it.

It'll probably get fixed and fade away, but if not, it's big.

 

[cryoburner]

I've always been happier, in principle, with lots of physical cores rather than half real cores and half virtual ones. The OS doesn't help when it exposes logical cores without distinguishing between real and SMT, leaving it up to the software developers to figure out which is which when it matters.

The benefits of SMT are that you can more efficiently run two threads on a single core. When a processor core is executing instructions, there will be times when that core is waiting for an instruction to complete, during which the inactive parts of the core can be used for executing other instructions. It doesn't add much to the size of a CPU core to add SMT, so it effectively gives it more multithreaded performance for the cost to produce it, as well as more performance for a given level of power draw. Even if a processor has "lots of physical cores", in a task that utilizes as many cores as it has to offer, not having SMT will leave those cores underutilized, and you will effectively be leaving some multithreaded performance on the table.

 

[greenreaper]

A different mitigation to just disabling SMT might be to just make sure SMT threads are all allocated to the same VPS of a cloud host? That way only code from the same client can be on the threads of the same core.

Most VPSs are two or more threads anyway these days, so it may already be done that way.

Indeed; Google Cloud will give you a free e2-micro VM running at 0.25 of a vCPU, consisting of 0.125 of two threads on one core. This renders SMT vulnerabilities ineffective and possibly improves cache locality (since the shared cache may be used to operate on the same code/data), although it also means that you are competing for shared processing blocks. Still, you can do quite a lot with it, since it'll effectively burst to full speed for a brief time - I run an 18-box munin monitoring master on mine.