12 ms·
Intel Performance Hit 5x Harder Than AMD After Spectre, Meltdown Patches
- wtallis 7y agoOriginal source: https://www.phoronix.com/scan.php?page=article&item=intel-mds-xeon&num=1 https://www.phoronix.com/scan.php?page=article&item=intel-md...
- aristophenes 7y agoNot exactly the right link, that is for the server chips. This one is for the consumer CPUs: https://www.phoronix.com/scan.php?page=article&item=mds-zombieload-mit&num=1 https://www.phoronix.com/scan.php?page=article&item=mds-zomb...
- Skunkleton 7y agoWhat are we supposed to draw from those graphs? The AMD part is already much slower than the intel part.
- bearjaws 7y agoI mean, a 15% reduction in effective computation is not nothing just because AMDs CPUs aren't faster. The 8700k has 2 less cores and costs ~$100 more, so now it is not a very compelling purchase if you plan to turn mitigations on. Many people bought the 8700k for a level of performance, that they now need to compromise for: 1) higher performance, small chance of exploits, 2) lower performance and less exploits. This dilemma did not exist until this year, and now everyone is paying for it, besides Intel.
- Skunkleton 7y agoThe point is that it isn't comparable. It is likely that one of the reasons that the measured intel parts are so much faster is because of insecure optimizations. It would have been a much more interesting comparison to start from two SKUs with similar performance.
- deleted 7y ago[deleted]
- AnthonyMouse 7y agoIsn't that what they've done? The 6800K had been slightly faster than the 2700X, now it's significantly slower. The 8700K had been significantly faster than the 2700X, now it's slightly slower (and yet more expensive). The same for the 7980XE and the 2990WX.
- Dylan16807 7y ago> It is likely that one of the reasons that the measured intel parts are so much faster is because of insecure optimizations. I doubt it. The cost of workarounds is probably far worse than the time saved from using unsafe methods.
- tschwimmer 7y agoI wonder if there's a sort of 'herd immunity' effect that would reduce your risk of not running the mitigations. Since the assumption is that this class of exploit is known and patched, it might be less attractive for exploit makers to target. Given that, you can actually disable the mitigation to get the performance back without suffering a breach. I wouldn't do this at a data center or a nuclear powerplant, but for personal workloads like gaming this might be an okay tradeoff.
- CogitoCogito 7y agoThis is basically one of the arguments why Linux doesn't have as many exploits. If Linux were in more widespread usage, then more focus would be put on exploiting it and hence running it without e.g. anti-virus or other mechanisms would be more dangerous. So Linux's relative market share might protect it more than many security choices in the OS. (I don't want to claim that any of the reasoning here is true, but I just wanted to point out the parallel to what you're saying.)
- scandinavian 7y agoWell, it remains to be seen if someone can even mount and attack against firefox or chrome. The researchers (RIDL) only managed ~1byte/s against a detached spidermonkey engine, with the old high-resolution timer enabled (these have been removed). They were not able to mount an attack against chrome. I have my doubts that we will ever see attempts at widespread exploitation against browsers. So not running mitigations for personal use/gaming would probably be absolutely fine.
- szbalint 7y agoGoogle attempted to fix Chrome against Spectre but gave up, so what you're saying about no feasible attack is not true. See: https://v8.dev/blog/spectre https://v8.dev/blog/spectre > we quickly discovered that software mitigation of all possible leaks due to Spectre was infeasible. Are there many other security issues that are easier to exploit with potentially higher impact? Sure. Does this mean that Spectre is fixed or can be mitigated in software? No. It's a bit like the formerly theoretical timing attacks against TLS: attacks only get better.
- isatty 7y agoI do have that CPU but I bought it because it was really close to the X series chips (feature wise) without the extra dime.
- robbyt 7y agoI wonder what other optimizations Intel have made, which could be potential security threats some day...
- listenandlearn 7y agoThings just keep getting better and better for AMD... it’s like once you have a little bit of luck things just keep snowballing from there. They are on track to have an amazing year with CPUs that may take a very significant chunk of the cloud compute away from intel and then maybe even on the performance side.. it’s just fascinating that a company that almost died just a few years ago is now a big contender on multiple fronts.
- adventured 7y agoI'm a fan of AMD, I hope they succeed. However, how do you figure things are getting better and better based on actual results? Right now it looks like they're going to be reset back to 2017 numbers, losing the business gains they made in 2018. Their sales have fallen for the last three quarters in a row, quarter over quarter, and they barely turned a profit last quarter. Sales imploded by 23% last quarter year over year. When does the amazing year start?
- jimbob45 7y agoIt starts when they get free positive publicity from scandals like this.
- aoeusnth1 7y agoLook at their own disclosures for 2019 H2 from their earnings statement - don't do your own estimate based on a linear projection of the last 3 quarters. 2019 is going to be an absolutely phenomenal year for AMD.
- wtallis 7y agoYou can't compare 2018 numbers to 2019 numbers without taking into account the intervening cryptocurrency crash. Setting that aside, their CPU and GPU sales have actually improved, even though both are nearing the end of a generation (and so are the console SoCs). The fact that AMD's still profitable even without cryptocurrency GPU sales is a pretty strong indicator of financial health, the likes of which they couldn't even dream of a few years ago.
- 7y ago
- lostmsu 7y agoThe title is clickbait, because 5x does not matter if the AMD's difference is under 1%. Also not the original source.
- Dylan16807 7y agoClickbait because it could be misleading in a counterfactual? 15% vs. 3% is pretty meaningful. 15-16% is comparable to the gap between 4th and 9th generation Intel processors at the same frequency. And in that time turbo has gotten better but base clocks have dropped.
- makomk 7y agoAlso, I think fully mitigating the security issues on Intel processors requires applying all the patches and disabling hyperthreading, at which point you're seeing more like a 20+% impact on performance. In particular, from what I can tell the microcode and software patches for RIDL and ZombieLoad only flushes the state on context switches and cannot protect against the hyperhreading-based variants of the attacks.
- dijit 7y agoLoss of hyper-threading is only "20%+" because you put a plus there.. Hyper-threading in synthetic workloads is usually in the order of 40% loss in performance. Depending on how well used the hyper-threads are it can actually be higher. It's unlikely to be lower than 40% unless you're bottlenecked before the CPU (memory speed or heavy CPU cache invalidation)
- maffydub 7y agoThe article says... "Disabling [hyperthreading] increases the overall performance impact to 20 percent (for the 7980XE), 24.8 percent (8700K) and 20.5 percent (6800K)." ...so I think a performance impact of "20%+" (i.e. 20% or more) is fair - for the 8700K it's 24.8%.
- imtringued 7y ago
- hinkley 7y agoWhat’s the cost of interprocessor communication versus clearing these caches so aggressively? I wonder, as cores continue to increase, if another solution will present itself in the form of segregating traffic per processor.
- viraptor 7y agoThose who care already do this. NUMA is taking advantage of memory locality by itself, and processes can be pinned to cores manually as well. But even reading memory of your own process can be an issue (it is for browser tabs)
- hinkley 7y agoThe browser is providing OS services so if those services are “broken” they have to be fixed twice. Wouldn’t one process per origin and letting the OS do its job reduce the surface area here?
- ryacko 7y agoDispatch units are slowly increasing in number, and there is enough registers to octuple threads per core. It isn't hard to imagine a future where multithreaded applications with write disabled executable memory would be faster to the point where browsers will stop using JIT as we know it.
- alkonaut 7y agoAs far as I understood, the solution to this in sandboxes such as the js world, is simply to deny anyone using timers with a resolution that could reveal cache misses. How much is software really relying on timers with this resolution? What would it mean if CPU manufacturers simply gave up and said "to mitigate side channels, you can't have a clock that is so accurate that it lets you measure whether X has happened because knowing that is equivalent to reading any memory". Or, instead of detecting various things and flushing out sensitive data on some context switch, the CPU just adds noise to the timers instead? I'm gussing this is a complete no-go, but I'm wondering why it is?
- ss248 7y agoIf you really want to, you can "manufacture" high resolution timer pretty easily with thread spinning.
- mmrezaie 7y agoI am excited. Can you give an example? Also, if there is any use for it in system software for it?
- alkonaut 7y agoI suppose then "adding timing noise" here would also require making sure instructions don't have fixed and dependable execution times, because then you can just manufacture a clock by incrementing a number and knowing how many clock cycles the increment is. So an increment cannot be a known number of cycles. It does sound messy.
- amelius 7y agoBut then you'd have to increase execution times, and here we are ...
- alkonaut 7y agoThat's true of course. So basically adding timing noise is equivalent to adding artificial slowdowns. The only upside I suppose is that it might solve all timing sidechannel attacks in one go. So it's not 3% for one and 4% for the next and so on. It's a one time cost to disable timing as an attack vector.
- joaomacp 7y agoIf I'm not wrong, these are kernel patches. Intel is adding hardware (they call it in-silicon) mitigations to Meltdown (in Coffee Lake [1]) and Spectre (in Ice Lake[2]). This should help increase performance again, right? I'm actually waiting for Ice Lake before buying a new laptop. [1] https://www.tomshardware.com/news/intel-9th-generation-coffee-lake-refresh,37898.html https://www.tomshardware.com/news/intel-9th-generation-coffe... [2] https://en.wikipedia.org/wiki/Ice_Lake_(microarchitecture) https://en.wikipedia.org/wiki/Ice_Lake_(microarchitecture)
- rwmj 7y agoDoes anyone have the full kernel command line to turn all of the mitigations off? I don't need this on my private development server which runs all code either written by me or under my control.
- pabs3 7y agohttps://make-linux-fast-again.com/ https://make-linux-fast-again.com/
- afroboy 7y agoThat's why average joe doesn't like Linux. how i'm going to use this?
- simfoo 7y agohttps://wiki.ubuntu.com/Kernel/KernelBootParameters https://wiki.ubuntu.com/Kernel/KernelBootParameters
- Zardoz84 7y agoYou must put it on kernel options, somewhere on grub config files.
- ChrisSD 7y agoThe "average joe" shouldn't be doing this.
- Asooka 7y ago> That's why average joe doesn't like Linux Having seen the attempts at making Linux friendly for theoretical frictionless spherical Joes in vacuum, I'd rather just have my 1-2% market share GNU/Linux OS for unix greybeards, warts and all. The friendly GUI shell on top of Linux for average Joes is called Chrome OS and Android.
- zamadatix 7y agoIn 5.2 (next major release) the "mitigations=off" flag should cover it all. Up until recently there wasn't really a need for such a catch-all so it hadn't been made.
- JoeAltmaier 7y agoAdmitting all the issues with this 'attack' as given, I can't help thinking this is only an issue because, CPUs use the old 'secrecy as security' model. E.g. if we add to each thread an encryption key used to interpret every memory access (just an xor with a rolling mask) then access to somebody else's memory become access to an encrypted document with a key you don't know. No longer a problem?
- zrm 7y agoThese are really timing attacks. It's not a matter of directly reading the data, it's a matter of being able to deduce what's there based on how long it takes to do it.
- JoeAltmaier 7y agoYes; but that would be irrelevant if they didn't depend on secrecy for security, right?
- zrm 7y agoAh, you're proposing a solution for Meltdown rather than Spectre. The difference is that with Meltdown there is speculative access to memory that isn't even mapped to the original process. Memory encryption might work as a way to solve that, but we already know how to solve that -- do what AMD and others have been doing the whole time and don't continue speculative execution through a page fault.
- JoeAltmaier 7y ago...until somebody finds another vector to reveal the value of Kernel memory. The mantra is, secrecy is not security. The User/Kernel dichotomy flagrantly ignores this principle.
- InTheArena 7y agoAt some point we need to start pointing the blame directly at Intel here. It’s becoming more and more obvious that this isn’t a problem where modern CPU architecture didn’t anticipate a security attack vector — but more that Intel took shortcuts with security infrastructure on the chip in order to improve their IPC count.