[ZDNet] Intel CPUs impacted by new PortSmash side-channel vulnerability

[DaveSimmons]

The Finnish researchers said they couldn't afford to buy a Ryzen setup to test. Many academics do not have million-dollar research grants. Associate professors without tenure get paid peanuts and can barely pay their bills.

. “(The real reason is we don’t have the [hardware] to test it on at the moment, so we have to wait.)”

https://arstechnica.com/information...erthreading-exploit-that-pilfers-crypto-keys/

So no, they aren't being "politically correct" or lying about AMD.

My reading of this is a threat level much lower than Spectre and Meltdown. You have to be able to run native code on the same core as the crypto library, and the library has to be vulnerable to timing attacks.

That's on the same core NOT just on the same CPU. I'd hope that by now that Google, Azure and AWS cloud setups all avoid sharing cores between customers.

 

[Abwx]

So no, they aren't being "politically correct" or lying about AMD.

.

Intel CPUs are impacted and for AMD they dont have the slightest clue since they did no test, as such the shouldnt even say "probably" or "likely" but just that in the current state of affairs they cant give any indication about AMD being vulnerable or not.

Any other statement is just pure political correctness, as if they were afraid to not give the bully the deference they grant him usually.

 

[DaveSimmons]

Intel CPUs are impacted and for AMD they dont have the slightest clue since they did no test, as such the shouldnt even say "probably" or "likely" but just that in the current state of affairs they cant give any indication about AMD being vulnerable or not.

Any other statement is just pure political correctness, as if they were afraid to not give the bully the deference they grant him usually.

They have more than that, it's an educated guess by people much more educated on the subject than you and me. They think that it can be made to work on AMD and possibly anything else with SMT because it does not depend on speculative execution or on an intel-specific implementation of SMT. It's just an information leak between two threads running on the same core.

 

[LTC8K6]

A spokesperson for AMD told us they're looking into it: "At AMD, security is a top priority and we are continually working to ensure the safety of our users as new risks arise. We are investigating the PortSmash side-channel vulnerability report, which we just received, to understand any potential AMD product susceptibility"

Posted again, since a few folks don't want to know...
AMD has not been tested.

 

[Markfw]

Posted again, since a few folks don't want to know...
AMD has not been tested.

We have known that since the OP, why are you trying to keep reposting ? It will not change anything.

 

[LTC8K6]

We have known that since the OP, why are you trying to keep reposting ? It will not change anything.

Twice is too many times?
Okay, noted.

 

[DrMrLordX]

Why it's always like this?
They discover and test the flaws in Intel chips but not on AMD chips? They just wrap it up with "we suspect"?
This is ridiculous, or they test and see or they say nothing.

You would think, at a university, they could find at least one person with a Ryzen setup somewhere that would cooperate with them. Load a test binary on a USB-mounted Linux install, unhook all other drives (just in case), and boot from USB. Done deal. Cost: maybe 1 USB stick?

An Intel spokesperson

Yes, let's ask Intel about whether it affects AMD hardware.

The Finnish researchers said they couldn't afford to buy a Ryzen setup to test.

See above. I can sort-of understand how maybe AMD would be unresponsive to some random Finnish researchers if AMD's front office is incompetent (they may be). But cmon, surely SOMEONE with a Ryzen system in the wild would let them run a test, once they had a binary that was working on Intel hardware. At least just one little test. Maybe they would have to recode the attack to expose vulnerabilities on the AMD system. That might require more time with the test machine.

 

[DaveSimmons]

You would think, at a university, they could find at least one person with a Ryzen setup somewhere that would cooperate with them. Load a test binary on a USB-mounted Linux install, unhook all other drives (just in case), and boot from USB. Done deal. Cost: maybe 1 USB stick?

Yes, let's ask Intel about whether it affects AMD hardware.

See above. I can sort-of understand how maybe AMD would be unresponsive to some random Finnish researchers if AMD's front office is incompetent (they may be). But cmon, surely SOMEONE with a Ryzen system in the wild would let them run a test, once they had a binary that was working on Intel hardware. At least just one little test. Maybe they would have to recode the attack to expose vulnerabilities on the AMD system. That might require more time with the test machine.

I don't think they expect the assembly code written for those 2 CPUs to "just work" on anything else. Notice that they don't claim it works or does not work on any other intel CPU families either?

" Intel Skylake and Kaby Lake chips and Ubuntu, worked by sending one logical core a steady stream of instructions and carefully measuring the time it took for them to get executed."

They worked with these 2 CPUs until they got the timing for the exploit to work, then stopped and released their findings. Coffee Lake? Sandy Bridge? AMD? Unknown, but there's no reason to expect them to be safe if the code is adjusted.

They're researching the technique, they aren't black hats trying to make it run on everything.

Edit: it also sounds like they're a small group on a tiny budget, and they might have wanted to release their findings as soon as possible to get the credit for discovery instead of waiting longer and borrowing other hardware to do more development work.

 

[DrMrLordX]

Notice that they don't claim it works or does not work on any other intel CPU families either?

No, but now that you mention it, you're right. They never said anything about it working/not working on Skylake-SP for example.

 

[Abwx]

Yes, let's ask Intel about whether it affects AMD hardware.

.

But they were prompt to state, even it was wrong, that AMD and ARM were impacted by Spectre/Meltdown, you can be sure that if they could had find such a deflection with this one they would had actioned the badmouthing one more time...

They have more than that, it's an educated guess by people much more educated on the subject than you and me. They think that it can be made to work on AMD and possibly anything else with SMT because it does not depend on speculative execution or on an intel-specific implementation of SMT. It's just an information leak between two threads running on the same core.

The mechanism rely on the fact that one kind of instruction is to be executed in a given port, and we know that AMD uarch is quite different at this level.


https://dendibakh.github.io/blog/2018/03/21/port-contention

 

[JoeRambo]

The mechanism rely on the fact that one kind of instruction is to be executed in a given port, and we know that AMD uarch is quite different at this level.

DIfferent, but also sharing the ports between SMT threads executing on same core and therefore more or less vulnerable to portsmash style attacks. Only Meltdown was unique to Intel and Power cpus, Spectre and Portsmash stuff is industry wide as long as CPU characteristics are known and precise enough timing is available.

The common thing between those attacks is that they are impacting Cloud and VM servers and have tiny risks for client CPUs. OS and software mitigations like ones built into Linux and soon coming into Windows 10 are plenty to defeat them while keeping impact minimal.
Clients are most exposed via browsers, and all mainstream browsers have removed crucial and key component of attacks - precise timing. Without it it is pretty much impossible to abuse spectre/portsmash via web browsers.

 

[Atari2600]

Really poor form. The security scene is really devolving into a wild west where there are no rules and anything goes.

If you haven't tested it on another manufacturers architecture, then the public answer is "don't know, haven't tested it".

Privately, you also supply the information to all manufacturers you *think* *might* be vulnerable at the same time as you supply it to manufacturers you *know* *are* vulnerable.

 

[Vattila]

"AMD processors likely impacted"

Since this exploit works by analysing side-effects in the specific implementation of SMT — in particular, side-effects from resource sharing among the hardware threads — and considering these things differ between Intel and AMD's microarchitectures, it is highly likely that the proof-of-concept code only works on the intended target, i.e. some Intel processor generation and models.

While in theory it probably is possible to write a similar exploit for AMD's SMT implementation in Zen — or any hardware multi-threading architecture that shares resources between threads — who will care to target AMD? AMD's installed base in servers is probably far less than 1% (they are targeting ~5% of new sales by the end of this quarter). An attack on AMD EPYC would be very targeted, probably an attack on a single organisation known to run AMD servers.

That said, it is still a vulnerability that AMD must consider if it affects their processors.

In any case, this issue only affects deployments that allow non-trusted processes to execute threads on the same core as other processes. This seams easy to limit in the operating system (by adjusting the thread scheduler to not allow processes to execute simultaneously on the same physical core), or in the hypervisor that partitions VMs to guests/clients (by not allowing different VMs to share physical cores). Disabling SMT altogether, while perhaps a necessary temporary solution, seems draconian.

Am I missing something?

 

[DaveSimmons]

In any case, this issue only affects deployments that allow non-trusted processes to execute threads on the same core as other processes. This seams easy to limit in the operating system (by adjusting the thread scheduler to not allow processes to execute simultaneously on the same physical core), or in the hypervisor that partitions VMs to guests/clients (by not allowing different VMs to share physical cores). Disabling SMT altogether, while perhaps a necessary temporary solution, seems draconian.

Am I missing something?

That's my understanding as well. Cloud services like AWS allocate resources by real cores not thread/virtual cores so my guess is they are already safe.

I don't know whether typical VPS software keeps the VPSs on separate cores or not. If not, that is what needs to be fixed.

Cheap shared web hosting with 1,000+ sites on one server and no partitioning of cores is probably theoretically vulnerable but not really because of the odds of getting paired up on the same core as the site you want to attack are going to be slim to none.

 

[HotJob]

My take from what I read on it:

1) This is more useful as a a method of building an exploit than to actually compromise a machine. Since the exploit and the encryption have to be running on different threads on the same core, the machine is already compromised.

2) My 6 year-ish old FX-8350 gaming machine with Cluster Multithreading is immune

 

[bononos]

Poor, really..?.

One month that Intel received the detailed info, they surely checked also for AMD systems but here all they had to say :

Update on November 2, 15:20 ET: An Intel spokesperson has provided the following statement in regards to the research team going public with details about the PortSmash flaw:

Intel received notice of the research. This issue is not reliant on speculative execution, and is therefore unrelated to Spectre, Meltdown or L1 Terminal Fault. We expect that it is not unique to Intel platforms.............

It sounds like their face-saving statement on the Spectre/Meltdown scandal as well. When in trouble, try to rope in AMD and ARM with you.

https://www.hardwarezone.com.sg/tech-news-read-intel-s-statement-meltdown-and-spectre-exploits:
Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings

 

[wahdangun]

so in the end, AMD implementation of CMT is more secure and future proofing int term of security ?

so can we expect maybe some variant amd zen with CMT design ?

 

[DaveSimmons]

so in the end, AMD implementation of CMT is more secure and future proofing int term of security ?

so can we expect maybe some variant amd zen with CMT design ?

CMT (cluster-based multithreading) is AMD marketing BS for a cluster of CPUs. (And Hyperthreading is intel's marketing BS for SMT .)

I think you mean SMT = simultaneous multithreading = 2 threads running on one core.

Is AMDs SMT safer? Not known.

The researchers only developed the exploit on the two intel servers they had access to (Skylake and Kaby Lake). Once it was working they made their report.

They made no effort to get the exploit working on other intel CPU generations like Coffee Lake or Sandy Bridge, or any AMD CPUs, or any other CPU with SMT.

 

[wahdangun]

CMT (cluster-based multithreading) is AMD marketing BS for a cluster of CPUs. (And Hyperthreading is intel's marketing BS for SMT .)

I think you mean SMT = simultaneous multithreading = 2 threads running on one core.

Is AMDs SMT safer? Not known.

The researchers only developed the exploit on the two intel servers they had access to (Skylake and Kaby Lake). Once it was working they made their report.

They made no effort to get the exploit working on other intel CPU generations like Coffee Lake or Sandy Bridge, or any AMD CPUs, or any other CPU with SMT.

yes i know about AMD CMT design since its only share FP it can be much safer than SMT, and still saving some transistor budget.

I think you mean SMT = simultaneous multithreading = 2 threads running on one core.

Is AMDs SMT safer? Not known.

no, i mean if CMT design is safer, maybe they will design Zen with CMT, instead of SMT, or maybe fix several Bulldozer flaw.

 

[DaveSimmons]

yes i know about AMD CMT design since its only share FP it can be much safer than SMT, and still saving some transistor budget.

no, i mean if CMT design is safer, maybe they will design Zen with CMT, instead of SMT, or maybe fix several Bulldozer flaw.

https://en.wikichip.org/wiki/amd/microarchitectures/bulldozer

If anything, CMT probably allows for its own more serious set of exploits because with it parts of the CPU are shared between multiple cores. Anything shared opens the door to information leaks.

With it, you have to make sure the attacker process doesn't run on any of the cores in the cluster. With SMT and Hyperthreading (which is really SMT renamed) you only need to keep the other process away from your own one core.

The exploits are probably there, it's just that nobody cares about finding flaws in Bulldozer

 

[cytg111]

So, whats the performance penalty for this one ?? I am not buying a new CPU before these sploits quiet down and is fixed in hardware...

 

[LTC8K6]

So, whats the performance penalty for this one ?? I am not buying a new CPU before these sploits quiet down and is fixed in hardware...

Just buy a CPU without SMT/HT if you are worried.
It really isn't a factor for most users, just like Spectre and Meltdown aren't.
I have heard nothing about performance penalties from the SSL patch.

For portsmash, you already need to be able to execute code on the computer, so security must already be broken for it to happen.

PortSmash currently poses a threat mainly to people using computers or services that allow untrusted people to use the same physical processor.

 

[Abwx]

With it, you have to make sure the attacker process doesn't run on any of the cores in the cluster. With SMT and Hyperthreading (which is really SMT renamed) you only need to keep the other process away from your own one core.

With CMT only one thread is running per core, so it s safe by the definition, FP is SMT but not for a single core, only when the 2 cores are using the FPU each one with a single thread, beside the instructions used for this brute forced contention are INT.

What you re pointing for SMT to be safe is actually inherent with CMT, that is, there s no more than one process that is executed per core....

 

[DaveSimmons]

With CMT only one thread is running per core, so it s safe by the definition, FP is SMT but not for a single core, only when the 2 cores are using the FPU each one with a single thread, beside the instructions used for this brute forced contention are INT.

What you re pointing for SMT to be safe is actually inherent with CMT, that is, there s no more than one process that is executed per core....

https://en.wikichip.org/wiki/amd/microarchitectures/bulldozer

"Bulldozer shared one 4-pipe FPU, one L1 I-cache, one set of branch-prediction hardware, one 4-way instruction decoder, and the L2 unified cache between a pair of cores, referred to by AMD as a module. In the FX-8100 series CPUs, four modules were bundled together with a shared L3 cache, to make an 8-core CPU for the AM3+ socket. "

I was talking about side-channel leaks from the shared FPU, cache, branch hardware, decoder. If anyone bothered to try making exploits they might find data leaks or timing information based leaks.

 

[Abwx]

I was talking about side-channel leaks from the shared FPU, cache, branch hardware, decoder. If anyone bothered to try making exploits they might find data leaks or timing information based leaks.

But the leaks must be acquired from a single core contention, and here it is useless to try anything on the FPU since even if it s SMT the initalisation and completion of each process is managed by the two separate cores.