Hacker News Reader

Comment by walterbell | Hacker News Reader

Does this mean AMD hyperthreading has a performance + security advantage over currently shipping Intel processors?

Edit: https://www.amd.com/en/corporate/security-updates

> 8/14/18 – Updated: As in the case with Meltdown, we believe our processors are not susceptible to these new speculative execution attack variants: L1 Terminal Fault – SGX (also known as Foreshadow) CVE 2018-3615, L1 Terminal Fault – OS/SMM (also known as Foreshadow-NG) CVE 2018-3620, and L1 Terminal Fault – VMM (also known as Foreshadow-NG) CVE 2018-3646, due to our hardware paging architecture protections. We are advising customers running AMD EPYC™ processors in their data centers, including in virtualized environments, to not implement Foreshadow-related software mitigations for their AMD platforms.

For those on AMD platforms, how do you disable software mitigations for Foreshadow? Is this automatically done by browsers, operating systems and hypervisors?

View on HN

They've been unsusceptible to some of the more recent side-channel attacks, but others have affected everything from Intel to AMD to ARM.

I haven't really ready anything on this most recent set of vulnerabilities and AMD.

There is a lot of false equivalence going on about the vulnerability of Intel vs everyone else.

Yes spectre type issues effect many ranges of processor (including AMD), however everything shown to date indicates that its very difficult to exploit.

There are a large number of Intel only issues like meltdown and the L1 cache attack that are much more severe, and much easier to exploit.

With the newer AMD processors having as many real cores as they do, does the cost-benefit analysis of HT/SMT change? I read in a comment here a few weeks ago that turning it off on the newer AMD CPUs can yield better performance because of improved cache-coherency on some workloads (My memory of what I read might be totally wrong).

Yes, but it's often a case where deploying finer-grained explicit parallelism works in favor, due to the much longer dependency chains that can be hid by the second thread. There are architectures not impacted by this issue, mostly ones with explicit dependency tagging long enough to handle a dTLB fault, but you need closer to double the registers and interleaving by the compiler to get abotu the same performance as with SMT-2 (aka, hyperthreading).

I'll defer to whatever the benchmarks say of course, but I don't see why HT would affect cache coherency for normal workloads. If you disable HT you'd still have the same number of threads/processes running on the system, so you still have to schedule the same amount of work and do the same number of context switches.

Suppose you have 8 runnable processes and a 4 core / 8 thread system.

With 4 execution units, 4 processes run at a time, and they all get swapped out every scheduling tick (losing all their cached lines). OTOH each process gets a full measure of cache to use during its slice.

With 8 execution units, 8 processes "run" at a time, they interleave based on stalls and CPU resources, and the OS doesn't need to reschedule anything every tick (so they hopefully keep their cache lines hot). But each process gets a half measure of cache to use.

In reality, code tuned to use a full measure of cache will be better off matching the number of processes to the number of execution units available, so you'd run half the number of processes with HT disabled. And cache-tuned code tends to fall off a performance cliff when it exceeds cache available, so it may easily run more than twice as fast, depending on the work.

The win from HT depends on most code not being tuned to full measures of cache, and having a lot of memory stalls or other heterogeneous work that other work can fit into. And most code is like that. Cache tends to have a declining marginal return - you have to add exponentially more cache to avoid cache misses - https://en.wikipedia.org/wiki/Power_law_of_cache_misses .

The working set at any point in time might be larger with HT and and less likely to fit in cache.

some of the heavily multithreaded applications I use at work see up to a ~27% loss in performance by disabling SMT, others don't see much of a loss at all (on AMD EPYC)

maybe. no guarantee AMD won't have the same issue.

For hypervisors it's automatic. For operating systems, there's no performance penalty. Browsers need not do anything.

Unless the browser is using hypervisor https://arstechnica.com/information-technology/2016/09/windo...

It's still the hypervisor (Hyper-V in that case) that has to do the work to mitigate the vulnerability, not the browser. The browser just uses whatever APIs the hypervisor exposes to create a virtual machine.

Yes!

Where did you get that impression?

AMD claims their processors aren't affected at all by any of the 3 variants of Foreshadow (https://www.amd.com/en/corporate/security-updates) therefore SMT is safe to leave enabled. On the other hand, on Intel the only fully comprehensive workaround is to completely disable SMT, so given that disabling SMT almost halves the performance on some workloads,¹ AMD is bound to have a huge performance advantage over Intel, on these particular workloads.

¹ For example in SPECvirt_sc2013 the patch reduces performance by 31% (https://www.servethehome.com/wp-content/uploads/2018/08/Inte...) 31% is unheard of for a security patch! It's a difficult security-speed tradeoff that businesses must carefully consider.

Should truth-in-advertising laws require OEMs to stop advertising hyper-threading, e.g. 4C/8T on new hardware, if the advertised feature is not fit for purpose?

My personal opinion is "not yet".

Give intel some time to cope with this newest set of vulns, see if they can find a way to re-enable hyper threading safely, and if they can't and are still advertising hyper threading, then start going after them.

I believe it may be because the email only mentioned Intel explicitly and had a "I won't be buying Intel in future" (paraphrased) comment. However, I personally wouldn't assume that AMDs HT implementation doesn't have similar issues.

> However, I personally wouldn't assume that AMDs HT implementation doesn't have similar issues.

It does not. The fundamental difference between AMD and Intel CPUs in all these faults is that AMD does all permissions checks eagerly before returning results from memory, while when speculating, Intel defers them until speculation is resolved.

This does not mean that AMD escaped all of it, because some of the attacks (eg, spectre variant 1) do not cross a protection boundary that permissions checks would catch.

HT is also disabled on AMD, for both CMT (FPU-shared) & SMT implementations.

https://marc.info/?l=openbsd-cvs&m=152954666609919&w=2

While no AMD issues are known at present. OpenBSD will have it disabled by default. How about other operating systems, I wonder?

Possibly, but it's not uncommon to refer to x86 and x64 machines as intel architecture machines or as intel machines.

Due to architectural differences, AMD CPUs are immune or nearly immune to some of the speculative execution attacks (though not all of them). For example, AMDs branch predictor uses the full address and so is not vulnerable to branch predictor poisoning in the same way as Intel.

The major win (whether AMD intended it or not) is that AMD cpus don't speculate loads until page permissions have been verified. Intel fires off the speculation immediately. That is one of the primary side channels underlying many of the attacks.

Intel has been actively muddying the waters with FUD to get people to think AMD is just as vulnerable. Please don’t buy into that. Intel is far more exposed. The subsequent slowdowns are more severe.

>Due to architectural differences

Microarchitectural differences. They are, after all the same architecture, i.e. x86-64.

/pedantic

Thanks for the clarification!

Reply on news.ycombinator.com