12 ms·
Analyzing Core I9-9900K performance with Spectre and Meltdown mitigations
- MR4D 8y agoConclusion at the end is fairly brutal: “The long and short of matters then is that based on the testing we've done thus far, it doesn't look like Coffee Lake Refresh recovers any of the performance the original Coffee Lake loses from the Meltdown and Spectre fixes. Coffee Lake was always less impacted than older architectures, but whatever performance hit it took remains in the Refresh CPU design.”
- duxup 8y agoForgive me as I'm nowhere near knowledgeable in CPUs or such so my terminology will be way off. For any CPU designed with the expectation of using the old method of memory access prediction without any protections... can we expect they'll ever show a significant performance recovery? I guess I always assumed the answer was no.
- ethbro 8y ago(Someone please correct me if I'm wrong) Without adding additional hardware, likely not significant. The way you avoid some of the impacted scenarios (at modest performance impact) is with additional hardware or microarchitecture changes. Basically, the task is 'Ensure processor state, as observed by another process, never changes because of speculative execution branches.' Which is a high bar to meet, especially if you want to simultaneously optimize your execution unit utilization.
- chx 8y agoThat is pretty obvious if you consider this is just another tweak of the venerable Skylake architecture. By now we have said good bye to the reasonable thermals we enjoyed for a while because, well, if you deliver six of the same cores that'll consume 50% more at the same clock so one hand you slow down the chip when all cores run and on another, you just allow it to consume more.
- blattimwind 8y agoAnd Skylake itself wasn't a new design either, but rather a tweak of Haswell (prominent changes were in the uncore), which in turn was largely identical to SB/IB.
- dantle 8y agoSkylake was a reasonably big core architecture upgrade (a "tock" in Intel terminology). Several new instructions (XSAVE, AVX512, etc.) were introduced. Perhaps you meant Broadwell?
- wtallis 8y agoConsumer Skylake and derivatives didn't get AVX512; that's reserved for the server parts that arrived two years later.
- chx 8y agoIt's been benchmarked that from Sandy Bridge to Kaby Lake the IPC only grew 20% https://www.hardocp.com/article/2017/01/13/kaby_lake_7700k_vs_sandy_bridge_2600k_ipc_review/4 https://www.hardocp.com/article/2017/01/13/kaby_lake_7700k_v... but the power efficiency has brutally increased: This is a 35W CPU in 2011 https://browser.geekbench.com/processors/381 https://browser.geekbench.com/processors/381 and this is an Y (4.5-7W) CPU from 2017 https://browser.geekbench.com/processors/1822 https://browser.geekbench.com/processors/1822 .
- hu3 8y agoTLDR: hardware patch is as slow as the software one. Except now it's a bit worse since I cannot disable the patch to recuperate lost performance.
- eganist 8y ago> I cannot disable the patch to recuperate lost performance. Knowing the actual, demonstrated risks... why would you do this? I'm not trying to devalue your position. I'm trying to understand your risk calculation. --- Edit: Good catch, humans. The thought of running code in an unexposed, isolated, largely trusted environment didn't cross my mind; I was moreso focused on the environments I'm used to (where everything is connected and nothing is trusted). That said, I'd argue that a database backend to any typical webapp definitely qualifies as exposed.
- rndgermandude 8y agoI'm going with the herd immunity for my personal stuff. The calculation is basically: their_waste = likelihood enough people have the mitigations enabled (not tech enough to disable them) so that "bad people" will not waste time developing exploits for the tiny number of unprotected people like me (herd protecting me) my_risk = likelihood of "bad people" actually finding me and being able to run their code their_reward = likelihood of them actually finding something meaningful and valuable in the memory they can manage to dump oops = (my_risk * their_reward) / their_waste I am assuming my_risk and their_reward to be low and their_waste to be high, so oops will be acceptably low (hopefully :p) Wish me luck!
- benologist 8y agoServer logs are full of scripts and people trying to penetrate services with old, known bugs that have been widely neutralized for years.... it doesn't cost much to try one exploit.
- rndgermandude 8y agoSo far there haven't any mass exploits for these CPU bugs targeting personal systems like mine in the wild. The most risk comes from web browsers as you can execute (constrained) attack code in those. That's why browser vendors were busy disabling SharedArrayBuffer real quick and developed further mitigations that hinder exploiting CPU bugs like these. I may reconsider when browser-based exploits become a real thing that is in widespread use. People probing my ports and exposed services running on my machines is far less of an issue since I don't run any service designed to run attacker supplied (but sandboxed) code like a browser does. If somebody managed to run code anyway (RCE) then I probably would have other problems than just worrying about somebody running spectre exploit code ;) As it stands right now, the prime targets are shared execution environments running untrusted sandboxed code, aka cloud providers needing to worry that customer A's VM doesn't dump the memory of customer B's VM running on the same hardware.
- AmVess 8y agoWhat a horrible test. They tested without hyperthreading turned on. Spectre and Meltdown are risks BECAUSE of hyperthreading. It makes zero sense to test the performance impact of the fixes with the major component of the problem turned off.
- BeeOnRope 8y agoNeither Spectre nor Meltdown are related to hyperthreading.
- tux3 8y agoYou're right that Spectre and Meltdown are not related to SMT, but that doesn't invalidate the wider point about hyper-threading and side-channel issues I think. Parent may have simply meant TLBleed/L1TF (Foreshadow) instead of Meltdown/Spectre.
- BeeOnRope 8y agoI'm not trying to invalidate any wider point about hyperthreading, and the original article wasn't trying to make one. It was specifically about Spectre and Meltdown mitigations which are unrelated to hyperthreading, so testing with or without hyperthreading is fine. Bringing up hyperthreading here is like bringing up how a diet high in salt is unhealthy, someone pointing out that salt has nothing to do with the original article, and then a final comment "Yeah, but that doesn't invalidate the wider point that we should consume less salt!".
- sigi45 8y agoI will look it up later but i thought hyperthreading increases it. Perhaps i'm mixing something up but i thought that intel removed smt from the newer generations (is removing it) because of it.
- BeeOnRope 8y agoThere have been other recent vulnerabilities, like the ax/ah thing described in [1] or TLBleed that have relied on SMT, but not Meltdown or the original Spectre variants. [1] http://gallium.inria.fr/blog/intel-skylake-bug/ http://gallium.inria.fr/blog/intel-skylake-bug/
- tedunangst 8y agoHow did they confirm that the mitigations weren't still being used? If you're still using separate page tables for the kernel, well of course it's going to remain slow. The point of the fixed silicon is so you don't need the mitigation, not that the mitigation gets faster.
- opencl 8y agoThe "fixed silicon" at least so far mostly seems to be hardware implementations of the existing software mitigation techniques with very similar performance characteristics.
- tedunangst 8y agoCan we test this? Can we install an unpatched OS and observe the same performance penalty? In the case of meltdown, it seems unlikely the CPU is maintaining its own shadow page table. How would it do that?
- IntelMiner 8y agoYou could compile a Linux kernel with the Spectre defenses disabled. I assume userspace software that includes mitgations could also be patched out in the same way for testing
- tarlinian 8y agoI agree, I remember reading this article and thinking something was odd...how could you implement page table isolation in hardware? The Spectre improvement could plausibly be more similar to software mitigation...
- quotemstr 8y agoAnd that's a shame, since in principle, the hardware can do better than software. I've heard of approaches ranging from better cache partitioning to transactional commit to cache on instruction retirement. I can only imagine that Intel is working on these systemic fixes in the next big microarchitecture revision while continuing to apply cruder hacks on older cores that can't, say, alter low-level instruction retirement much.
- mbrumlow 8y agoI wonder how much Intel knew of this "bug" and went ahead and shipped with it because of the speed increases.
- duxup 8y agoI want to say I'm not giving them a pass but I think you can go overboard and "know" that "hey in theory someone could" and security yourself into never doing anything. Accordingly how much they knew about the nature of it and their ability to predict is really the question and IMO kinda a hard one to know (unless there are some memos out there) / judge. Granted in the age of little to no consideration given to security in so many places .... I wouldn't be surprised by anything.
- wmf 8y agoThis bug was designed around 1993 when security, multicore, and SMT didn't really exist.
- chandlerc1024 8y agoWorking closely with Intel and others on these issues I have seen zero evidence that anyone realized the security implications and shipped anyways. Zero evidence.
- blattimwind 8y agoKnowledge about this type of attack dates back to the 90s (possibly earlier), but it isn't entirely clear whether the engineers who developed the "protection check after [speculative] load" were aware of that. I would argue though that "check after load" should have smelled bad to people intimiately familiar with CPU design. It should be noted though that at the time neither sharing processors with strangers / across trust boundaries nor executing arbitrary crap in a VM were common activities. Memory protection and such were mostly viewed as a technique to increase reliability, not to provide actual security.
- leeoniya 8y agoat least we'll regain some lost spectre-related perf hits once MS ships their retpoline-patched kernel https://mspoweruser.com/windows-10-19h1-will-reduce-the-impact-of-spectre-mitigation-to-noise-level/ https://mspoweruser.com/windows-10-19h1-will-reduce-the-impa...
- greglindahl 8y agoDon't most machines with this kind of CPU in them not run Windows?
- Xylakant 8y agoMost maybe, but there’s still quite a large fleet of windows servers out there.
- leeoniya 8y agoi've seen js performance on synthetic benchmarks drop somewhat over the past months. perhaps JS JITs like V8 rely to some degree on specific branch prediction properties.
- gji 8y agoIf you’re talking about the i9-9900, it’s a very high clock frequency part with “only” 8 cores and part of the consumer line (no ecc support). I’d actually think most people who have it run Windows and use it for things like gaming.
- billman 8y agoI would love to see a benchmark for VM performance before and after.
- roadkillon101 8y agoHow would you write a program to use these exploit? Unless I'm mistaken, I'm under the impression you have to talk directly to the processor through the kernel in order to do any of these exploit. You would have to write the code in assembler or use a special library to do predictive branching?
- __bjoernd 8y agoYes, you'd write some assembly or C. Or your start from existing demos: https://samsclass.info/123/proj14/spectre.htm https://samsclass.info/123/proj14/spectre.htm
- saagarjha 8y agoYou don't need to write assembly or C; it is possible to perform an exploit by utilizing any high-resolution clock, like the one JavaScript on most browsers provided until recently.
- sigi45 8y agoYour code always talks directly to the cpu. Your program 'just' runs in a env where it is not allowed to do a few things the kernel is allowed to. Probing the cpu for timings of memory access you don't have access to, or forcing it to something somewhere where you do have access to, you don't need the kernel for that. Thats the problem.
- __bjoernd 8y agoPerformance is all nice and such. Did anyone validate that the new processors actually mitigate Spectre and Meltdown?
- fooker 8y agoThey mitigate Spectre specifically but not speculative execution bugs in general, which it seeems will be with us for the foreseeable future.
- jammygit 8y agoWhat does this mean for developers buying laptops or workstations in the next year - is amd or raptor looking like a better choice, or is Intel still looking good even after the hit? I'm reading that workstations might not need to worry for the most part for example, unless a package gets compromised or some browser exploit makes it through
- syn_rst 8y agoI built a workstation with a Threadripper earlier this year, and I couldn't be happier so far. The single-core performance advantage of Intel parts isn't that big, and you get a ton of cores and PCIe lanes in exchange.
- scottlocklin 8y agoThey should make a "miss me yet?" meme for Itanium.