
How Screwed is Intel without Hyper-Threading? - rbanffy
https://www.techspot.com/article/1850-how-screwed-is-intel-no-hyper-threading/
======
old-gregg
The very first graph (Cinebench R15) is wrong. i7-8700K does not score 3314 or
even 2515 on this benchmark [1]. i7-7700K numbers are also way off. Not sure
what happened here, but I can't take any other measurement they published
seriously. This is more useful:
[https://www.phoronix.com/scan.php?page=article&item=sandy-
fx...](https://www.phoronix.com/scan.php?page=article&item=sandy-fx-
zombieload&num=3)

If you're using an overclockable workstation CPU, the good news is that
turning SMT off gives you additional ~200Hz of overclocking headroom. Modern
Intel chips are thermally limited when overclocking and turning SMT off makes
them run a bit cooler. My i9-7900X overheats over 4.4Ghz, but with SMT off
it's comfortable at 4.7Ghz on air (Noctua D15).

[1] [https://www.guru3d.com/news-story/intel-
core-i7-8700k-benchm...](https://www.guru3d.com/news-story/intel-
core-i7-8700k-benchmarks.html)

~~~
Yetanfou
> the good news is that turning SMT off gives you additional ~200Hz of
> overclocking headroom

That'd be 200 MHz, not 200 Hz?

~~~
rzzzt
Not on my MOS 6502!

~~~
duskwuff
The concept of a hyperthreaded 6502 is intriguing, and I wish to subscribe to
your newsletter...

------
TEMPEST256
Another micro-architecture attack. Since the advent of Spectre and Meltdown, I
really wonder what is the practicality of exploiting these vulnerabilities. As
an end-user, if I have malware running on my machine trying to trigger these
exploits, then in many ways I have already lost. The malware program has
access to all my personal data anyway.

Personally I wonder whether the cost of mitigation is worth it. According to
the article (and their simplified HT methodology) certain workloads experience
a 25% performance hit.

The only cases I currently consider as exploitable are VMs in the cloud
(perhaps a reason to own dedicated servers after all this time) and running JS
in the browser (perhaps a reason to disable JS).

There will always be side-channel attacks. Our devices are physical devices
and will leak side-effects, like electromagnetic radiation (
[https://en.wikipedia.org/wiki/Tempest_(codename)](https://en.wikipedia.org/wiki/Tempest_\(codename\))
). This recent spate of MDS flaws don't necessarily fit in my threat model.

~~~
feanaro
Hopefully you'll agree that there is a world of difference between an
electromagnetic side-channel and something that can be achieved by simply
running some JS.

In particular, disabling JS would be pretty disabling for an average modern
web user, so an easy, practical attack through this vector is especially
relevant.

~~~
dijit
Yet every time I ask my web developer friends to ensure that functionality
works online without JavaScript for basic things I am met with hostility.

If we were able to run without JavaScript and have basic use of websites again
then these attack vectors wouldn’t be so scary.

Maybe it’s a personal failing of mine; but I don’t understand why people don’t
consider JavaScript untrusted code when other vectors of running software on
my machine come from a gpg-signed chain of custody.

~~~
overgard
Well, you would have to architect an app from the ground up to be functional
with/without javascript and test any new functionality with it off. You’re
talking 2x the work to appease maybe .0005% of the web browsing public. I
wouldn’t be hostile if you asked me to do that... but I wouldn’t entertain the
idea seriously either.

~~~
hdfbdtbcdg
If you build using server side rendered HTML then progressive enhancement with
JavaScript is not actually that difficult. It takes a different mindset that
most webdevs don't have. Getting the UX nice for the fallback is hard.

~~~
mantap
Yes _if_, but many websites have moved on to client side rendering because if
done right it delivers a better user experience for the 99% of users that have
JS turned on, because there is no latency between page transitions.

Sure, passive content such as nytimes.com can work without JS (although some
of their interactive articles would not), but anything more complicated will
often be done with client side rendering these days.

~~~
sitkack
> no latency between page transitions

Not true, latency scales with CPU capacity on the client. SPAs now exist with
client side rendering to mask the bloat in the site plus its dependencies.

If you have a SPA arch but you did a page load per click, you would die. But
all sites creep up to 500ms page load times regardless of their starting stack
and timings.

------
wolf550e
Intel's doc [1] if SMT is not disabled, not only does the OS need to perform
group scheduling (only allow threads that trust each other to run on the same
core at the same time) but the OS also has to interrupt the sibling thread
running on the same core whenever user mode code enters kernel mode,
synchronizing syscalls. For compute-heavy applications, this might be ok, but
for servers doing a lot of syscalls this might be terrible.

1 - See "Synchronized ring 0 entry and exit using IPIs" in
[https://software.intel.com/security-software-
guidance/insigh...](https://software.intel.com/security-software-
guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling)

~~~
amluto
I haven’t seen a Linux implementation of this yet, but I suspect the
performance is beyond terrible. Intel’s doc says:

> There is no hardware support for atomic transition of both threads between
> kernel and user states, so the OS should use standard software techniques to
> synchronize the threads.

Ha, “standard software techniques”. Let’s see: suppose one thread finishes a
syscall. Now it sets some flag telling the other core to wake up and go back
to user code as well. But the other core is running with interrupts on. So now
we sit there spinning until the other core is done, and then both cores turn
off interrupts and _recheck that they both still want to go to user mode_.
This involves some fun lock-free programming. I suppose one could call this a
“standard software technique” with a somewhat straight face.

Meanwhile, the IPI on entry involves an IPI and the associated (huge!)
overhead of an x86 interrupt. x86 interrupts are incredibly slow. The IPI
request itself is done via the APIC, and legacy APIC access is also incredibly
slow. There’s a fancy thing called X2APIC that makes it reasonably fast, but
for whatever reason, most BIOSes don’t seem to enable it.

I suspect that relatively few workloads will benefit from all of this. Just
turning off SMT sounds like a better idea.

~~~
nimish
Much like many late model intel cpu features x2apic was buggy at launch and so
people disabled it by default.

------
FartyMcFarter
The article says that disabling hyper-threading is a worst case scenario, but
I don't think it is.

Intel themselves said [1] "Intel is not recommending that Intel® HT be
disabled, and it’s important to understand that doing so does not alone
provide protection against MDS."

[1] [https://www.intel.com/content/www/us/en/architecture-and-
tec...](https://www.intel.com/content/www/us/en/architecture-and-
technology/mds.html)

~~~
makomk
Indeed. In order to protect against MDS on Intel chips, you need to disable
hyperthreading _and_ apply microcode and OS updates which have their own
additional performance penalties on top of that.

~~~
jand
If my understanding of the announced updates [1] is correct, the need to
update exists for non-HT CPU, too (see C3000 series and such).

[1]
[https://www.intel.com/content/dam/www/public/us/en/documents...](https://www.intel.com/content/dam/www/public/us/en/documents/corporate-
information/SA00233-microcode-update-guidance_05132019.pdf)

------
ianlevesque
Honestly the cure is worse than the disease with these “vulnerabilities.” How
do I opt out of the 10-25% performance hit for an extremely speculative
vulnerability?

~~~
anaphor
On Linux you can just ignore the intel-ucode package (or whatever it's called)
and not update your CPU microcode. BUT, I think they also have mitigations in
the kernel, so you would have to not update your kernel, or somehow remove the
patches.

~~~
tanderson92
[https://make-linux-fast-again.com/](https://make-linux-fast-again.com/)

------
gtirloni
I can't find any recent news about class action suits against Intel. It seems
everything is from early 2018.

Is this situation so unexpected that major companies don't even know how to
react? If I were Amazon or Google, I'd be requesting my 30% discount,
retroactively. Perhaps they are?

~~~
ithkuil
Probably a condition for getting that discount is to promise to not make it
public.

------
klingonopera
On a sidenote, does anybody else find it interesting that all the benchmarked
games running on Vulkan have only minimal performance hits?

IIRC Vulkan was designed to be more suited to modern multi-core processors,
and I believe that the "HT-agnosticism" it exhibits is good proof that they
managed that pretty well...

~~~
Narishma
I think it's more likely that the particular Vulkan games they tested are GPU-
bound, so a slower CPU won't have much of an effect on their framerate. I mean
Doom even runs at 60 fps on current-gen consoles' low-powered CPUs.

~~~
klingonopera
Maybe they are GPU-bound precisely because the CPU-intensive parts are so well
done with Vulkan?

~~~
Narishma
I don't think so. DX12 has the same performance characteristics as Vulkan, yet
the DX12 games tested show performance degradation when HT is disabled but
Vulkan games do not. As I said, I think it's because the particular Vulkan
games tested happen to be more GPU-bound than the DX12 ones.

------
petersellers
Does this mean that the vulnerability doesn't affect CPUs that don't have
Hyperthreading (e.g. the 9700K - 8 cores/8 threads)?

------
rocky1138
How realistic are these attacks for every day desktop users?

------
MaxBarraclough
If we want securely-isolated low-horsepower machines, why don't we just fill
server-racks with large numbers of low-horsepower physical computers, rather
than small numbers of big-iron computers using software isolation in the form
of VMs?

Wouldn't that win half the battle, at least on server-side? It wouldn't apply
to workstations, of course. Malicious/untrusted processes running there would
still need to be isolated (malicious JavaScript in the browser, say).

Also, am I missing something, or are these concerns really not applicable to
gaming applications (which the article emphasises)? That's a highly trusted
codebase, so securely containing it isn't worth a 15% performance hit, no?

~~~
nexuist
The cloud is only able to be cost effective because they are able to utilize
those fleets of big-iron computers to provide nearly infinite VMs and
resources to anyone who signs up for their services. Relegating each customer
to their own physical computer would raise costs so high as to essentially
eliminate the purpose of the cloud's existence, and most businesses would be
better off going back to their own data centers at that point.

~~~
sigstoat
> Relegating each customer to their own physical computer would raise costs so
> high as to essentially eliminate the purpose of the cloud's existence

plenty of places rent bare metal machines, and the price doesn't seem quite
that world-ending. see packet.net for instance.

and it only gets better if on the bare metal machine you get to turn off all
of the performance-draining fixes.

~~~
angry_octet
It's actually much cheaper than cloud. It doesn't have the scaling
flexibility, but that is partially compensated for by running faster, lower
latency, etc. Lots of people use Cloudfront etc but still host on their own
bare metal.

~~~
MaxBarraclough
Isn't it still 'cloud'? It's still _on a server somewhere that I don 't think
about_, which is really all 'cloud' tends to mean.

I don't care whether Amazon use virtualisation to get me my 'instance'.
They're always careful to stick with 'instance', and never to commit to 'VM'.
Wise move, now that they're offering physical ('dedicated') instances [0].
Time will tell whether they take an interest in low-horsepower dedicated
instances.

[0] [https://aws.amazon.com/ec2/pricing/dedicated-
instances/](https://aws.amazon.com/ec2/pricing/dedicated-instances/)

~~~
angry_octet
There is a non-smooth transition from a server you own/lease and sits in
specific rack in a known data centre with well understood routing and one
provisioned as a dedicated instance in AWS/Azure etc that you manage with an
API.

------
wnevets
How much do these problems actually affect normal users tho? AFAIK not a
single exploit has been created using meltdown or spectre, and why would there
be?

------
alkonaut
For 10-15% FPS I'd take any vulnerability any day of the week. I'd easily
accept wiping my machine every night and never browsing the web on the same
machine if that's what's required. I can just get another machine for whatever
other task I have and it's pocket change compared to the gaming machine.

~~~
p1mrx
There might be a way to block the patch, but having a computer _strictly for
gaming_ makes you a bit of an outlier.

~~~
CWuestefeld
an outlier, but not a unicorn. Dedicated machines running RetroPie for gaming
is very much a thing. Probably most people doing this use a RPi (so not
Intel), there's a lot of us buying old OptiPlexes and stuff.

~~~
lkschubert8
People running RetroPie are unicorns of unicorns in terms of the people using
computers. Hell even people gaming are unicorns in terms of overall computer
usage.

~~~
CWuestefeld
I disagree. I can think of at least three use cases that frequently employ
Intel CPUs, and that involve running a limited set of low-risk software:

* Gaming-only machines, like my RetroPie example.

* Media servers, like for Plex or Kodi.

* NAS servers, powered by software like UNRAID.

~~~
lkschubert8
But those uses are still smaller than rounding errors in terms of overall
usage.

~~~
CWuestefeld
It's big enough to create whole markets for commercial software, as my
examples of Plex and UNRAID show.

------
robertAngst
Can anyone explain attack vectors? How does this happen?

------
cannedslime
So does this mean that I will get a performance hit with the comming windows
update?

Is there any way to mitigate this performance drop, disable the fix?

------
earenndil
Interesting that they measure FPS instead of frametime. FPS doesn't scale
linearly, but frametime does.

------
panarky
Pretty cool business model where putting dangerous vulns in your product can
help you capture 90% of the market.

Then when your fuckups are discovered, other people not on your payroll expend
their own resources to fix it.

And you don't even have to compensate customers who paid full price but now
find 40% of their compute evaporated.

And that massive performance hit needed to fix your fuckups stimulates
incremental demand for your product because customers now need more cores to
finish their compute.

~~~
McGlockenshire
> Pretty cool business model where putting dangerous vulns in your product can
> help you capture 90% of the market.

This is extremely disingenuous phrasing. You seem to be trying to craft a
narrative that makes putting security vulnerabilities in products an
intentional thing to sabotage people, time, and resources.

~~~
myself248
At some point, I bet someone in a design meeting said "Hey, I think this might
compromise security, can we study that before implementing it?"

And the decision to implement it without that study, or despite it, was made.
Because implementing it increased performance which made the numbers which
captured market share.

It's not like the processor designed itself that way. Humans made choices
along the way, and every choice is a tradeoff. Execution-time attacks and
other sidechannel leakage have been well-known for years, and I can't imagine
that at a place like Intel, nobody had heard of that.

~~~
PeterisP
Why do you think that it's likely that someone in Intel design meetings had
thought of that if literally noone outside Intel did for many years?

It obviously wasn't obvious to the very, very many people worldwide who know
about execution-time attacks and other sidechannel leakage, as it took _more
than 10 years of almost every chip worldwide being vulnerable_ until it was
noticed. It's not as if some 2016 design tradeoff suddenly enabled Meltdown.
Engineers were carefully studying competitor's chip designs, and none of them
noticed that flaw for more than a decade.

~~~
viraptor
Even better: at least one person documented thinking about this issue, trying
to exploit it and failing - showing that even if you could come up with this,
it was really non trivial to achieve.

------
simonsays2
Gamers dont care about obscure vulnerabilities on their gaming rigs.

So I think this is some sort of misguided hit piece against intel.

Everyone knows pcs are riddled with security flaws less obscure than this.
People who run their business on cloud servers might care. Gamers though? No.

~~~
mfatica
They should care, considering some of these vulnerabilities are exploitable
just by JavaScript, meaning merely visiting a bad website could leak sensitive
information

~~~
simonsays2
Lol. You are out of your league here fearmonger.

Gamers are are the 5 dollar whores of the security world, they are riddled
with bugs and the dont give a crap.

~~~
dang
We've banned this account for repeatedly violating the site guidelines. If you
don't want to be banned, you're welcome to email hn@ycombinator.com and give
us reason to believe that you'll follow the rules in the future.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

------
lone_haxx0r
Intel are consistently the assholes of the silicon market.

------
m0zg
Intel is not really screwed, cloud providers are. Those "vCPUs" people have
been buying are actually hyperthreads. I have a hypothesis that a double digit
percentage of cloud customers don't know what vCPUs are. As a cloud provide,
imagine cutting your fake "core capacity" in half _and_ having to raise prices
to offset the increased capex.

~~~
AaronFriel
I've had difficulty parsing the guidance from Google for Google Kubernetes
Engine here: [https://cloud.google.com/kubernetes-engine/docs/security-
bul...](https://cloud.google.com/kubernetes-engine/docs/security-
bulletins#may-14-2019)

> Note that n1-standard-1 (the GKE default), g1-small and f1-micro VMs only
> expose 1 vCPU to the guest environment so there is no need to disable Hyper-
> Threading.

I'm wondering if they've decided to just eat the loss on the single vCPU
nodes, and for vCPUs >= 2, they pass the decision on to the customer.

Or is there someone else's VM running on the other hyperthread?

Here's their guidance on machine types:
[https://cloud.google.com/compute/docs/machine-
types](https://cloud.google.com/compute/docs/machine-types)

> For the n1 series of machine types, a vCPU is implemented as a single
> hardware hyper-thread on one of the available CPU Platforms.

------
josteink
Wow. Even more Intel CPU vulnerabilities. I hadn’t even _heard_ about MDS
until now. Glad I based my new rig on the Ryzen stack.

I wonder how much these continuous performance degradations are costing bigger
customers, like cloud operators. This shit can’t be cheap.

