How Screwed is Intel without Hyper-Threading?

https://www.techspot.com/article/1850-how-screwed-is-intel-no-hyper-threading/

by rbanffy • 7 years ago

232 213 7 years ago

josteink• 7 years ago

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.

FartyMcFarter• 7 years ago

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...

makomk3• 7 years ago

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• 7 years ago

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...

simonsays23• 7 years ago

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• 7 years ago

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

simonsays23• 7 years ago

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.

bartimus• 7 years ago

Did not know this. Thanks.

https://react-etc.net/entry/javascript-spectre-meltdown-vuln...

ryacko• 7 years ago

This however does remove the benefits of ASLR.

The only two mitigations is either disabling hyper-threading or disabling JIT.

simion3142• 7 years ago

I bought a non K CPU (without hyper threading) , If I would have bought the K version and later Intel announces "disable the hyperthreads to be 100% safe" I would not be happy, even if I am 99.99% safe with HT on, (I personally did not enable or disable any security thing, I run the Ubuntu defaults).

IMO Intel customers should not be indifferent, what you thought you bought was not what you got latter, you lost performance and you have to do advanced stuff to disable the security patches and be unsafe

Edit: My bad, I considering buying i7 and got an i5 , I got confused(my i5 is a K CPU 6th gen).

jefft255• 7 years ago

The K thing is about overclockability, not HT.

onli• 7 years ago

Which processor did you buy where the K version has hyperthreading and the non-K does not? I don't think that distinction exists in any Intel cpu generation. K just means unlocked and sometimes a higher clock, it says nothing about hyperthreading.

adrianN• 7 years ago

Intel doesn't make its profits with gamers. It's data centers that buy Intel chips by the boatload.

asveikau• 7 years ago

I have no data, but it would have to seem to me that gamers are a tiny market compared to what Intel sells in any given year.

NullPrefix• 7 years ago

Some games have internal currency or items that can be sold. I'm pretty sure there's malware targetting those items.

paulie_a• 7 years ago

Gamers are not the only target market. Gamers are a fairly small market.

znpy• 7 years ago

"Gamers" don't game 100% of the time. They also do normal web browsing (possibly to buy the next gaming pc).

Your argument is invalid.

panarky4• 7 years ago

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.

simonsays23• 7 years ago

At least as upstanding as sending your shills to bad mouth American products.

molticrystal• 7 years ago

Unlike previous speculative execution flaws that partially affected AMD and Arm-based processors, the MDS flaws are exclusive to Intel chips.

This isn't an excuse for Intel and how they (sometimes poorly) handle issues that come up. And it is well known that many of these vulnerabilities are currently specific to Intel and how their subsystems are implemented, or only exist on Intel processors. But side-channel attacks are a nearly universal vulnerability.

SMT of which Hyper-Threading is an implementation of is used in many chips from many companies, AMD's Bulldozer, IBM's POWER, Sun/Oracle's Sparc, etc.

These exploits are not a monolithic process, but many techniques chained together to get most of these exploits to work, and this common knowledgebase which has been refined by the researches will most certainly be recycled and reused on other processors.

If anything, the "capture 90% of the market." by Intel as you put it only ensures that these problems will usually be discovered on their processor's first.

If as much effort was put towards other cpus as it is towards Intel, you would see significant performance hits as well with them.

dfrage16• 7 years ago

Expanding on your points, only AMD, SPARC and MIPS avoided Meltdown bugs, they were also found in ARM, and IBM POWER and mainframe/Z designs. All of these vendors have out-of-order speculative execution designs that are vulnerable to Spectre.

If anything, the "capture 90% of the market." by Intel as you put it only ensures that these problems will usually be discovered on their processor's first.

Precisely. I haven't looked at the MDS set of flaws yet, but to take the first version of Foreshadow/L1TF, it targets the Intel SGX enclave, by definition the designs of other companies that don't have SGX won't be vulnerable. But as you note this doesn't mean they don't have their own design or implementation specific bugs.

BubRoss• 7 years ago

That's all in retrospect - Intel hasn't even really dropped their prices or increased their core counts from AMD competition or security disasters.

Narishma3• 7 years ago

Why would they? They keep selling all the chips they can make at their current prices.

McGlockenshire• 7 years ago

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.

panarky4• 7 years ago

Of course it's not "an intentional thing to sabotage people, time, and resources".

It's intentional business decision to maximize performance and minimize costs paid by Intel, making their products faster and generating higher margins.

They achieved this by gambling that vulns wouldn't be exploitable. But Intel externalized that risk onto their customers and partners without their knowledge or consent.

So when the gamble failed, the rest of the ecosystem bears the cost while Intel harvests the gains for themselves.

Externalizing risks and losses on others without their knowledge or consent is a form of theft.

myself2482• 7 years ago

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.

amelius2• 7 years ago

That would only be valid as a short-term strategy.

dfrage16• 7 years ago

And for Intel these bugs go back to the first Pentium Pro in 1995, their first out-of-order speculative execution design. Very cunning of them, along with IBM two years earlier, the SPARC bunch starting that year, MIPS and AMD a year later, and recently ARM as it targeted higher performance to follow the same exactly "strategy".

Or maybe it was an industry blind spot, now a very big deal because so many of these CPUs run other people's random code, JavaScript in browsers, and anything and everything in shared cloud hosts.

tntn5• 7 years ago

And how about the generations of computer architecture professors that have promulgated the lie that is "architecturally visible state," am I right? Speculative execution is fine, cause we just throw away the results before they become architecturally visible.

Those professors aren't doing too bad now either, with plenty of papers to be published outlining the flaws and proposing solutions.

Really, though, humanity is still pretty new to this whole computer architecture thing in general, and running untrusted code securely in particular. Im skeptical that someone at Intel was aware for the possibility of vulnerabilities for 10+ years before any of them were made public.

To be honest, I'm a little perplexed by the animosity directed towards Intel after all these vulnerabilities. Vulnerabilities in software are most frequently the result of ignorance, but everyone seems to assume the engineers and managers at Intel knew better (or should have know better). Who would have told them?

throwaway20483• 7 years ago

It was known since the Pentium 4 era that hyper-threading had serious timing attack concerns, concerns Intel seems to have completely ignored.

http://www.daemonology.net/hyperthreading-considered-harmful...

Spooky232• 7 years ago

Who are these customers?

In my case, we observed very marginal performance impacts from last year’s mitigations.

teddyh• 7 years ago

“Put more bugs in the software! I’m making a fortune out here!”

https://dilbert.com/strip/2000-03-19

gtirloni• 7 years ago

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• 7 years ago

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

TEMPEST256• 7 years ago

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) ). This recent spate of MDS flaws don't necessarily fit in my threat model.

userbinator• 7 years ago

No kidding, JS off by default and not running code you don't trust will always be a good idea. I also agree that I'm not really concerned about exploits that require running code on my machine; if the latter happens, I have far more serious things to worry about.

The exploits that do worry me, are ones that can be done remotely without any action from the user. Heartbleed is a good recent example. Fortunately those tend to be rare.

Security is always relative to a threat model, and not everyone wants perfect (if that can even be possible) security either, contrary to what a lot of the "security vultures" tend to believe.

scurvy3• 7 years ago

Supply chain attacks become a lot easier to pivot on. Put some Spectre code in a npm or RPM package, then wait to see what pops up. So much stuff is sudo curl pipe bash these days that the Spectre threat is real.

All the more reasons to run your own servers and compile your own binaries. Like we used to do.

elorant4• 7 years ago

Put some Spectre code in a npm or RPM package, then wait to see what pops up.

This is fucking scary. If it's a package used by Wordpress you could end-up with 30% of the web open to an attack.

vbezhenar5• 7 years ago

Why do you need Spectre for that? Just install backdoor. It's not like someone runs npm from restricted user.

acdha2• 7 years ago

You mean “compile your own binaries” using code which you downloaded without auditing, just like NPM? That’s actually what we used to do; blaming NPM is both reflecting a misunderstand of the problem and blaming the update system which means you can fix a problem orders of magnitude faster — the half-life of random tarballs people used was much longer.

feanaro2• 7 years ago

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• 7 years ago

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.

vbezhenar5• 7 years ago

Is there PoC website where I can get hacked via JavaScript exploiting those side-channel vulnerabilities? For me it sounds too theoretical.

jxdxbx• 7 years ago

it would rule if we moved away from javascript. it’s turned the web, the world’s best publishing platform, into the world’s crappiest app platform. good riddance.

rayiner4• 7 years ago

The fact that disabling arbitrary machine code execution would be “disabling” for the modern web is proof of how totally screwed up the whole thing has become.

rayiner4• 7 years ago

I feel like there is an impedance mismatch between what CPU designers think memory protection guarantees and what developers think memory protection offers. For production code, I never got much higher level than “C with classes” and if you asked me 15 years ago if leaking bits of information through the branch predictor or memory buffer was a failure to conform to the x86 memory protection model I would’ve said no. Memory protection is mainly there to keep one app from crashing another. If you’ve got untrusted machine code running on your system, you’ve already been compromised. I feel like CPU designers are still in that mindset. They still measure their success by how well they do on SPEC.

Maybe instead of slowing everything down for the sake of JavaScript, we need a special privilege mode for untrusted code that disables speculative execution, sharing a core with another hyper-thread, etc.

bsder• 7 years ago

If you’ve got untrusted machine code running on your system, you’ve already been compromised.

You are exactly correct. However, the advent of "The Cloud" changed that.

"The Cloud" by definition runs untrusted machine code right next to yours. IBM and other players have been screaming about Intel being insecure for decades--and it fell on deaf ears.

Well, suck it up buttercup, all your data are belong to us.

While I hear lots of whingeing, I don't see IBM's volumes rising as people move off of Intel chips onto something with real security. When it comes down to actually paying for security, people still blow it off.

And so it goes.

m0zg• 7 years ago

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• 7 years ago

I've had difficulty parsing the guidance from Google for Google Kubernetes Engine here: https://cloud.google.com/kubernetes-engine/docs/security-bul...

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

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

WrtCdEvrydy• 7 years ago

This is why the last version of AWS ARM had their vCPUs being 30% faster than regular vCPUs (no HT in ARM)

old-gregg2• 7 years ago

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...

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...

Yetanfou• 7 years ago

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

That'd be 200 MHz, not 200 Hz?

rzzzt• 7 years ago

Not on my MOS 6502!

old-gregg2• 7 years ago

Good catch, yes. :)

mappu• 7 years ago

I can't take any other measurement they published seriously.

Here's another problem with the article:

Microsoft is pushing out OS-level updates [...] However, this doesn’t mitigate the problem entirely, for that we need motherboard BIOS updates and reportedly Intel has released the new microcode to motherboard partners. However as of writing no new BIOS revisions have been released to the public.

That's wrong - microcode updates can be successfully applied by either the OS or by the early-boot firmware, you do not need a BIOS update (just apt update intel-microcode).

p1mrx2• 7 years ago

They probably ran the benchmarks on Windows. Is it possible to customize the microcode version on Windows without a patch from Microsoft?

Syzygies• 7 years ago

Bingo. Hyperthreading does not pay for itself, overclocking. Period. End of discussion. I turn it off, or buy chips without it.

gambiting• 7 years ago

Overlocking is not an option on 99% of laptops.

justinclift• 7 years ago

The text around it says Cinebench R20 too. Guessing both were tested, and the wrong data set was pasted into the article.

  "First off we have Cinebench R20 results ..."

martinpw• 7 years ago

There is an R20 8700k score listed here which is close to the one quoted in the Techspot article (3372 vs 3314):

https://www.geeks3d.com/20190306/tested-cinebench-r20-cpu-be...

So Techspot numbers are fine, just a typo on version of benchmark, should say R20 on graph not R15.

emn13• 7 years ago

Just note that the perf loss is 20-40% in their benchmarks, so in your case, you'd need to bump that 4.4Ghz to 5.5-73.GHz, which is a tall order.

In any case, the article is worst-case FUD-like nonsense. No idea what the eventual perf loss will be, but it's a safe bet it'll be less than that.

Consider that it's likely safe enough for 99% of usages for the OS to allocate CPU cores to processes in pairs, and that would incur only a small penalty. And something smarter is almost certainly possible, too.

wolf550e• 7 years ago

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...

amluto• 7 years ago

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• 7 years ago

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

petersellers• 7 years ago

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

lone_haxx0r• 7 years ago

Intel are consistently the assholes of the silicon market.

wnevets• 7 years ago

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?

ianlevesque2• 7 years ago

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?

elorant4• 7 years ago

Don't apply updates. For desktop computers the risk is practically non-existent. Servers and VPSs are the ones taking the hit.

ianlevesque2• 7 years ago

I still want the fixes for actual vulnerabilities though.

batoure2• 7 years ago

I think this is bad advice, yes there is a performance hit but chances are any eventual malware (which lets be honest if it doesn't already exist is being written as we speak) that exploits these vulns will in its execution probably impact your system with a negative performance hit.

The "don't apply the updates" argument in security is basically philosophically comparable to the antivax movement

anaphor• 7 years ago

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• 7 years ago

https://make-linux-fast-again.com/

0x76• 7 years ago

For most of the mitigations there are kernel parameters to disable them if you wish to do so

wtallis• 7 years ago

The CPU microcode updates are also delivered through motherboard firmware updates, so you'd have to avoid those too. But some of the microcode updates permit more efficient mitigations, so unless you can completely avoid software updates with mitigations, you might actually want some of the microcode updates.

vengefulduck• 7 years ago

In Linux you can disable mitigations with kernel parameters.

zeckalpha2• 7 years ago

“Speculative” does not mean this isn’t a vulnerability. It is describing execution that happens when the CPU guesses which code will execute after a condition. There is a vulnerability with speculative execution, not a speculative vulnerability with execution.

batoure2• 7 years ago

Agreed, I think the nuance here is that in compsci terms "speculative" tends to mean "ok, so I can prove that architecturally that this is 100% possible. I simply lack (either) the labor hours needed to write code (or) the hardware/money resources to get this in place" within the bounds of infosec these types of proofs are taken very seriously on the principle of "if I figured this out with my shitty home lab people with serious resources can't be far behind" additionally responsible disclosure in this space generally means that originators of vulns usually get an undisclosed first shot at fixing problems like this and they only get published wide in this way when the fix is so serious and will require so much time that companies disclose them to avoid being held legally responsible for fraud at some later date.

MaxBarraclough11• 7 years ago

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• 7 years ago

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• 7 years ago

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.

MaxBarraclough11• 7 years ago

Relegating each customer to their own physical computer would raise costs

I'm not convinced the cost difference would be a showstopper. More little computers rather than few big computers. Same total horsepower. More motherboards, sure.

rubber_duck• 7 years ago

For certain kind of workloads renting bare metal is waay cheaper than VMs. What the small time bare metal providers cant compete with is all the different services sold along with the VMs. If it was just price per VM I suspect bare metal renting would be a lot more cost efficient in a lot of scenarios.

elorant4• 7 years ago

More machines means more power to cool them. Electricity bills are a big chunk of the cost of running a datacenter.

dfrage16• 7 years ago

I was just discussing this with a friend. Obviously there's a certain degree of multi-tenancy sharing that's most cost effective. For electrical power use and removing heat there's a floor where, if not being used, the best you could do would be to turn a system off, which has its own issues. Go too far and you won't be able to also run a spot market in CPU instances like AWS does.

MaxBarraclough11• 7 years ago

More machines means more power to cool them

That doesn't sound right. A large number of weak computers, should be easier to cool. A cluster of smartphones can get by with passive cooling, but my laptop cannot.

Apart from cooling, I'm not an expert on this but I don't know that performance-per-watt has to improve as overall power increases. Going with my idea you'll need to power more motherboards, but they'll be less powerful motherboards. (The total number of CPU cores being powered remains the same. Same goes for RAM modules.)

klingonopera3• 7 years ago

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...

Narishma3• 7 years ago

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.

klingonopera3• 7 years ago

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

rocky1138• 7 years ago

How realistic are these attacks for every day desktop users?

earenndil• 7 years ago

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

alkonaut2• 7 years ago

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.

p1mrx2• 7 years ago

There might be a way to block the patch, but having a computer strictly for gaming makes you a bit of an outlier.

CWuestefeld3• 7 years ago

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.

aaronmdjones2• 7 years ago

My only Windows machine is only used for gaming. It doesn't even have a web browser. It's also on its own VLAN, so it can't talk to my other machines.

alkonaut2• 7 years ago

It would yes, but my argument is this. Anyone who has a modern ("AAA" gaming machine) has probably paid a fair chunk of money for it. For a high end one, maybe $2-3k. Now consider how much of that money went into the last 10-15% performance of the machine. There are significant diminishing returns. It's for example the difference between a mid-range i5/i7 and the highest end i9 on the CPU end, or the difference between a 1660ti and a 2070 on the graphics card side. It's often several hundred dollars that went into the last 10%.

So: even if I built that machine to not be exclusively used for gaming (which would be an outlier), anyone who has a machine of that kind could easily motivate making it exclusive for gaming, because there is so much money in that 10-15% that we can buy a second much cheaper machine (e.g. a low end laptop, chromebook etc) to use for other things.

robertAngst• 7 years ago

Can anyone explain attack vectors? How does this happen?

cannedslime• 7 years ago

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?

How Screwed is Intel without Hyper-Threading?

Related Stories