LWN: Comments on "This week's hardware vulnerabilities"

This week's hardware vulnerabilities

jch — Thu, 21 Nov 2019 11:39:36 +0000

> However, we have many HPC workloads that gain nothing from hyperthreading.

Hyperthreading improves performance when a single thread is unable to exploit the resources of a core, e.g. because of cache misses or bad instruction scheduling. With carefully vectorised, FPU-bound code, you're not going to see a lot of improvement.

A lot of us are memory-bound or run non-vectorised code, and so we find hyperthreading useful.

This week's hardware vulnerabilities

roblucid — Mon, 18 Nov 2019 10:43:44 +0000

English is not written with the precision of a programing language and most words have several meanings, it's an error or an erratum to use the -ultra-pedantic option!

erratum

halla — Fri, 15 Nov 2019 15:49:28 +0000

Well, one shouldn't use a Latin dictionary for English, not even when the word used is still recognizably Latin, of course. That said, the English dictionary definition is still error, but the habit of titling a list of corrigenda for a book with "Errata" or "Erratum" means that people these days think an Erratum as a list of corrections, not a list of errors.

And since living languages change, that's going to be the meaning of the word, no matter what dictionaries say.

erratum

robbe — Fri, 15 Nov 2019 15:12:30 +0000

As my 1980 Latin dictionary translates „erratum“ as mistake or error, it seems you that are going astray.

This week's hardware vulnerabilities

kpfleming — Fri, 15 Nov 2019 09:56:11 +0000

"A microcode update (MCU) can prevent this erratum."

What? The MCU can go back in time to erase the evidence that the problem existed? Amazing.

"Erratum" is the report of the issue, not the issue (misbehavior) itself. Bad writing, Intel. Bad.

One word missing from this article

pm215 — Thu, 14 Nov 2019 10:35:12 +0000

Like SVE2, TME is not a part of any specific v8.x architecture version. I think you can find instruction details and pseudocode in this document: https://developer.arm.com/docs/ddi0602/b ("Arm® A64 Instruction Set Architecture: Future Architecture Technologies in the A architecture profile").

This week's hardware vulnerabilities

nivedita76 — Wed, 13 Nov 2019 21:43:33 +0000

Not really that recent. IIRC it was broken on the first generation (Haswell) and was enabled on Broadwell.

This week's hardware vulnerabilities

hmh — Wed, 13 Nov 2019 21:31:37 +0000

The JCC erratum is a disaster, its fix is already present in the 20191112 microcode batch, and that fix comes with a decent performance penalty.

And the proposed patches to llvm and gas to get some of that performance back appear to worsen the cache footprint for everyone if enabled by distros like Debian and Ubuntu. That is unacceptable as far as I am concerned. OTOH they're good ideas for JIT that detects the need at runtime, and host-specific building distros like Gentoo that can do host specific optimization.

This week's hardware vulnerabilities

Cyberax — Wed, 13 Nov 2019 18:42:48 +0000

Example: https://www.phoronix.com/scan.php?page=news_item&px=R...

This week's hardware vulnerabilities

luto — Wed, 13 Nov 2019 16:15:23 +0000

Citation, please. As I understand it, it doesn’t seem to offer much benefit in practice.

This week's hardware vulnerabilities

rc — Wed, 13 Nov 2019 15:55:47 +0000

That is certainly true for a lot of workloads. However, we have many HPC workloads that gain nothing from hyperthreading. Many HPC sites have historically disabled hyperthreading since it was introduced, although recent iterations had started getting good enough (and some code is bad enough IMO) that enabling it was starting to make sense to help those few edge cases. But with these kinds of problem on multi-user systems? Disabled.

Again, to each their own. For our uses cases it just makes sense to disable hyperthreading.

This week's hardware vulnerabilities

Baughn — Wed, 13 Nov 2019 14:40:10 +0000

That would be a 40% performance loss on my workloads, for a threat that's still mostly theoretical.

This week's hardware vulnerabilities

joib — Wed, 13 Nov 2019 07:05:04 +0000

Another vulnerability that was apparently made public today is the "JCC erratum", where a jump instruction straddles a 32B boundary. See https://www.intel.com/content/www/us/en/support/articles/...

The solution is yet another microcode update, and/or recompiling software with an option to the assembler to pad the code so that the affected jumps don't straddle the boundary.

This week's hardware vulnerabilities

Cyberax — Wed, 13 Nov 2019 05:38:03 +0000

It got re-enabled on the recent CPUs. I guess it's going to be disabled again.

Pity, it offers really nice performance improvements.

This week's hardware vulnerabilities

dmoulding — Wed, 13 Nov 2019 05:33:03 +0000

I don't always buy new CPUs, but when I do, I buy the ones without HT.

This week's hardware vulnerabilities

flussence — Wed, 13 Nov 2019 03:39:02 +0000

I thought TSX was already disabled by microcode because it was broken by design, or did newer chips solve that?

One word missing from this article

brouhaha — Wed, 13 Nov 2019 00:23:42 +0000

Oops, apparently TME is not in v8.5-A. Maybe it's in v8.6A? For a feature that ARM officially announced seven months ago, it's frustrating that there seems to be no public reference documentation.

This week's hardware vulnerabilities

brouhaha — Wed, 13 Nov 2019 00:17:34 +0000

I'd rather keep TSX and disable Hyperthreading. AFAICT that would mitigate far more exploits than disabling TSX would.

One word missing from this article

brouhaha — Wed, 13 Nov 2019 00:15:56 +0000

ARM v8.5-A offers transactional memory. I haven't seen any word yet on whether the same exploit affects it.

One word missing from this article

leighbb — Tue, 12 Nov 2019 21:11:09 +0000

and that word is Intel. It would have been good to know that AMD is not affected.