|
https://www.tomshardware.com/news/intel-disable-hyper-threading-spectre-attack,39333.html https://sites.google.com/a/chromium.org/dev/chromium-os/mds-on-chromeos
|
#
?
May 14, 2019 18:56
|
|
|
|
| # ? Jun 12, 2024 03:17 |
|
|
3peat posted:https://www.tomshardware.com/news/intel-disable-hyper-threading-spectre-attack,39333.html Is hyperthreading more of a performance benefit on bigger Xeons than on the smaller client chips and Xeon E? How big of a deal is it to turn off hyperthreading on the big boys, Xeon Golds and Platinums?
|
|
#
?
May 14, 2019 19:50
|
|
|
Twerk from Home posted:Is hyperthreading more of a performance benefit on bigger Xeons than on the smaller client chips and Xeon E? How big of a deal is it to turn off hyperthreading on the big boys, Xeon Golds and Platinums? HT performance benefit is completely dependent on your workload being one that benefits from it. With that said, if you need a Gold/Plat Xeon with that many cores odds are your workload parallelizes well and will benefit from HT.
|
|
#
?
May 14, 2019 20:26
|
|
|
I guess the newest Cascade Lake Xeons already have mitigations for this.
|
|
#
?
May 14, 2019 20:32
|
|
|
It's more than just Zombieload today: https://cpu.fail/ RIDL and Fallout affect all current Intel CPUs and the only way to mitigate some of the attacks is to disable hyper-threading entirely: quote:Am I affected? Intel's Microcode updates apparently have a 3-9% performance hit and vendors are apparently recommending disabling hyperthreading (-30% performance) if you run untrusted code. That comes from a Reddit thread so I don't have anything more reliable than that to paste here. If this is as bad as the early reports are stating then this one really sucks.
|
|
#
?
May 14, 2019 20:39
|
|
|
*laughs in i5*
|
|
#
?
May 14, 2019 20:53
|
|
|
By the time these vulnerabilities stop hitting Intel is going to have regressed to Bulldozer IPC.
|
|
#
?
May 14, 2019 20:54
|
|
|
Number19 posted:disabling hyperthreading (-30% performance) 30% is kind of an absolute worst case. A lot of loads only get single-digit-percentage performance improvements from SMT.
|
|
#
?
May 14, 2019 20:59
|
|
|
Eletriarnation posted:30% is kind of an absolute worst case. A lot of loads only get single-digit-percentage performance improvements from SMT. Any performance hit metric will be workload dependent but having to turn off hyper threading is a pretty big deal
|
|
#
?
May 14, 2019 21:03
|
|
|
If you mean the actual chore of having to go turn it off on all the systems you manage is a big deal, I won't argue with that - I was only talking about the performance impact. I imagine a lot of systems have enough headroom for their relatively non-SMT-sensitive workloads to be fine with that part.
|
|
#
?
May 14, 2019 21:06
|
|
|
Eletriarnation posted:If you mean the actual chore of having to go turn it off on all the systems you manage is a big deal, I won't argue with that - I was only talking about the performance impact. Plus if you have a system that benefits greatly from it then losing up to 30% perf really loving sucks for your current server sizing plans
|
|
#
?
May 14, 2019 21:08
|
|
|
Yes. I am not arguing with the claim that the worst case is indeed very bad.
|
|
#
?
May 14, 2019 21:09
|
|
|
Eletriarnation posted:Yes. I am not arguing with the claim that the worst case is indeed very bad. I'd imagine cloud providers were none too thrilled when they heard about all this
|
|
#
?
May 14, 2019 21:10
|
|
|
There are a lot of things people do that benefit from SMT, what the gently caress are you on about with this "not a big deal" nonsense? These days even your web browser can use shitloads of threads.
|
|
#
?
May 16, 2019 05:43
|
|
|
I get to be all happy that the apps I used didn't benefit from SMT so I've always used a 5820K with hyperthreading disabled since it ran better for me anyways. I was actually thinking of rebenchmarking with a more modern set of apps to see if it still was true, but no need to worry about that now.
|
|
#
?
May 16, 2019 08:00
|
|
|
Apple released an update with an optional "high security mode" that disables HT and cuts performance by 40% in some cases. It's obviously disabled by default. Users of 10.14.5 also report another 20% eGPU performance drop, possibly related to the microcode updates. 
|
|
#
?
May 16, 2019 11:01
|
|
|
Disabling HT on a i7-3770 gets me 30 fps less in Division 2. So goddamn ready to move to AMD.
|
|
#
?
May 16, 2019 15:43
|
|
|
pofcorn posted:Disabling HT on a i7-3770 gets me 30 fps less in Division 2. If you have a 3770K, overclock it so you get back some of the lost performance from disabling HT. But I'm with you on wanting to move to AMD once Zen 2 becomes available because I'm still on a 2500k. spasticColon fucked around with this message at 16:16 on May 16, 2019 |
|
#
?
May 16, 2019 16:06
|
|
|
i aint disabling HT, they can eat my rear end has anyone seen a performance comparison after this latest patch and the new ME update?
|
|
#
?
May 16, 2019 17:11
|
|
|
Cygni posted:i aint disabling HT, they can eat my rear end I wouldn't mind seeing a pre/post all the patches.
|
|
#
?
May 16, 2019 18:28
|
|
|
what i'm not understanding about MDS is how do you induce the OS/VM/enclave or whatever to put the secret in the fill buffer repeatedly
|
|
#
?
May 16, 2019 18:43
|
|
|
So it’s time to go to AMD? Have there been any Zen2 leaks?
|
|
#
?
May 16, 2019 20:39
|
|
|
tehinternet posted:So it’s time to go to AMD? Have there been any Zen2 leaks? There have been a lot of leaks over the past few months but there's still a lot of open questions, most importantly clocks, pricing, and release date. What we do know for sure is that Ryzen 3000 (Zen 2) will have 8, 12, and 16 core models (all with SMT) with a 0-15% boost in IPC over the current models (depending on the workload), double the AVX2 throughput, and double the L3 cache of current models. On clocks, the engineering samples whose test results were leaked have mostly been clocked in the mid-low 3.x GHz range however it's pretty common for final clocks to be much higher with the question being by how much. I think everyone is expecting at least 4.5 GHz 1- or 2-core boost and there have been rumors that AMD has shown off parts boosting to 5.0 GHz to board partners, but those are just based on word from inside sources without any (public) documentary evidence. For pricing we're still not sure what AMD is thinking for their market strategy. Will they put the 12- and 16-core models in a new "R9" market segment above the current top-end "R7" and keep the current pricing on the 8-core and below SKUs? Will they move all the SKUs down a segment and give you 12 cores for the price of 8 (and 8 for 6, etc.)? There's good arguments to be made for why they would go with either approach and nobody outside AMD knows which strategy they will go for. Additionally we don't know the exact release date. Some slides from a recent investor presentation indicate Ryzen 3000 will be out by "Q3" but we don't know exactly what that means. It could mean it launches early next month (which would be "by" Q3) or it could mean a launch in September. I think most people are expecting early July (perhaps 7/7 to emphasize 7nm) based on that presentation. Hopefully our questions will be answered in a few weeks at AMD's Computex keynote. Mr.Radar fucked around with this message at 21:19 on May 16, 2019 |
|
#
?
May 16, 2019 21:15
|
|
|
One they have 20% better IPC than Haswell I’m jumping ship. Unless I can be 100% certain Intel’s new offerings are safe, but I think their chips might be hosed up fundamentally. They’re always cagey when asked if their newer chips will be fixed completely.
|
|
#
?
May 16, 2019 21:29
|
|
|
JawnV6 posted:what i'm not understanding about MDS is how do you induce the OS/VM/enclave or whatever to put the secret in the fill buffer repeatedly
|
|
#
?
May 16, 2019 21:31
|
|
|
Khorne posted:Most of the recent exploits are not a threat to consumers on their own hardware. okay? idk what that changes but sure, now we're on a cloud host, how do you induce the OS/VM/enclave/other VM guest or whatever to put their secrets into the fill buffer
|
|
#
?
May 16, 2019 21:35
|
|
|
Khorne posted:Most of the recent exploits are not a threat to consumers on their own hardware. They still allow leaking sandboxed process or kernel data to a non-privileged user processes. There's not usually much of payoff of executing that kind of attack against consumers but there's money to be made by stealing bank account creds or whatever someone is bound to try it.
|
|
#
?
May 16, 2019 21:36
|
|
|
JawnV6 posted:okay? idk what that changes but sure, now we're on a cloud host, how do you induce the OS/VM/enclave/other VM guest or whatever to put their secrets into the fill buffer You can't induce the OS/VM/etc to put things there. They have to have already put them in the relevant places "recently". Even with ZombieLoad, the biggest of the four recently disclosed exploits and possibly the most serious to date. You can see a proof of concept here. Khorne fucked around with this message at 21:51 on May 16, 2019 |
|
#
?
May 16, 2019 21:42
|
|
|
Khorne posted:You can't induce the OS/VM/etc to put things there. They have to have already put them in the relevant places "recently". Even with ZombieLoad, the biggest of the four recently disclosed exploits and possibly the most serious to date. code:
|
|
#
?
May 16, 2019 22:16
|
|
|
.
sincx fucked around with this message at 05:55 on Mar 23, 2021 |
|
#
?
May 16, 2019 22:32
|
|
|
So far none of these attacks have meant a drat thing to consumers after minor browser mitigations. As long as you can't exploit them through a web script, they're no threat at all. If someone's got you running their code on your local machine you're already completely owned.
|
|
#
?
May 16, 2019 22:44
|
|
|
I'm probably missing something here, but it seems like that it wouldn't really affect consumer/workstation workloads significantly to only allow hyperthreading on a core for threads spawned from the same application, which would also prevent use of the exploit unless the system is so compromised that it's probably not necessary anyway. Probably still wouldn't help server loads, but it shouldn't really be much a performance hit for gaming or workstation productivity where most of the workload is one or two applications spawning multiple threads.K8.0 posted:So far none of these attacks have meant a drat thing to consumers after minor browser mitigations. As long as you can't exploit them through a web script, they're no threat at all. If someone's got you running their code on your local machine you're already completely owned. Yeah, effectively this. Not so great for server farms, but also not super concerning for consumers?
|
|
#
?
May 16, 2019 22:45
|
|
|
sincx posted:That's like saying Boeing's 737 MAX design failure isn't a big deal because the plane only crashes occasionally and not all the time. It crashes 100% of the time with one damaged AoA vane.
|
|
#
?
May 16, 2019 23:11
|
|
|
K8.0 posted:So far none of these attacks have meant a drat thing to consumers after minor browser mitigations. As long as you can't exploit them through a web script, they're no threat at all. If someone's got you running their code on your local machine you're already completely owned. So you're saying that mandatory microcode updates that hurt real-world performance for consumers doesn't mean a thing? I'm actually surprised there's no class action lawsuit against Intel for selling processors based on advertised performance benchmarks that are now impossible to achieve in the real world due to microcode mitigations.
|
|
#
?
May 16, 2019 23:21
|
|
|
bobfather posted:So you're saying that mandatory microcode updates that hurt real-world performance for consumers doesn't mean a thing? K8.0 is saying the exploits aren't very meaningful to typical consumer workloads. If the mandatory microcode updates significantly affect consumer performance to address them, Intel has probably gone too far to get ahead on PR (and stumbled into another PR problem). Stickman fucked around with this message at 23:41 on May 16, 2019 |
|
#
?
May 16, 2019 23:39
|
|
|
sincx posted:That's like saying Boeing's 737 MAX design failure isn't a big deal because the plane only crashes occasionally and not all the time. The big deal, which is the failing of design, process, and culture in the company. The other deal, which is "what does this mean for me, a consumer". Media and people hype these up like it's going to happen to you. I've seen "your private browsing history is at risk" "your credit cards are at risk" "your passwords are at risk" all day. Unless you're individually targeted by state-level espionage teams, these are all pretty much non-threats. When the original spectre/meltdown dropped and it was possible to execute them from a javascript vm that wasn't even a credible threat. And that's the dream vector vs consumers. This is the kind of attack that gets placed into an official release of a piece of software that is commonly run by the organization being targeted. Even if you pull that off, you could run it for weeks, manage to get the data out, and still not extract what you were looking for. And analyzing the data is a herculean task in itself with these new exploits. You'd likely to have hope for something that gets ran near startup or shutdown, hope the targeted machine starts up and shuts down a lot, hope you end up on the same physical core, and compare the data to what you think is an identically built environment during startup/shutdown/normal use to get anything meaningful out of it. If someone successfully uses one of these attacks without relying on additional information about the environment or other exploits/compromised system type stuff my mind will be blown. The data analysis step alone seems daunting for most of these. They don't even come with memory addresses or any hints as to where the raw data came from, and it's going to be a mishmash of everything the CPU has been doing. Maybe I'm wrong and it's easier to get data out of these than I know. They seemed to have patched it before disclosure this time, but it's hard to tell if that's a PR move or due to it being that much of a threat. bobfather posted:So you're saying that mandatory microcode updates that hurt real-world performance for consumers doesn't mean a thing? Khorne fucked around with this message at 00:01 on May 17, 2019 |
|
#
?
May 16, 2019 23:40
|
|
|
are any of these security vulnerabilities actually possible and a threat to consumers in the real world or is this just infosec people trying to get their name out I get that the NSA might be able to use this against a target they have physical access to, but if you need multi-million dollars, months of setup time, and skilled penetration experts to pull an attack off, then the extra security frankly isn't worth the 30% performance hit. No one at their home buying things on Amazon is going to get their data stolen by these attacks. Shipon fucked around with this message at 00:09 on May 17, 2019 |
|
#
?
May 17, 2019 00:07
|
|
|
No one at their home buying things on Amazon gets a 30% performance hit from turning off HT either, if we're phrasing it like that. What we have right now is the most optimistic situation possible, "there's no practical exploit that we know of at this time." Might mean we'll never see one, might not.
|
|
#
?
May 17, 2019 01:43
|
|
|
There's an entire market of prosumers to small tech outfits that buy parts from places like Amazon and that would absolutely see material performance hits on applications ranging from GCC compilation to video encoding to even stuff like 7zip compression. A benchmark article from last year specifically on Intel SMT https://www.phoronix.com/scan.php?page=article&item=intel-ht-2018&num=1 quote:Long story short, Hyper Threading is still very much relevant in 2018 with current-generation Intel CPUs. In the threaded workloads that could scale past a few threads, HT/SMT on this Core i7 8700K processor yielded about a 30% performance improvement in many of these real-world test cases.
|
|
#
?
May 17, 2019 05:08
|
|
|
|
| # ? Jun 12, 2024 03:17 |
|
|
I don't think internal build servers or video encoding servers are really at risk of running untrusted javascript exploits. This is kind of like the "oh no database performance tanks from meltdown!" panic from last year. Solution: don't run a web browser on your database server. It's not running untrusted code. If MS or Oracle gets backdoored you are hosed anyway. Frontends, sure, you take a big hit, backend stuff is going to be fine anyway.
Paul MaudDib fucked around with this message at 05:52 on May 17, 2019 |
|
#
?
May 17, 2019 05:48
|
|
