Intel making us slow down
-
The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit.
...
It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the contents of protected kernel memory.Yikes. This sounds like a pretty big deal.
The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.
LOL.
-
What's stopping a VM running on, say, EC2, from exploiting the vuln to access data on other VMs running on the same hypervisor?
-
@lolwhat After the fix it'll be too slow to do the attack
-
@hungrier Of course, the performance hit will also be a compelling argument against running just about anything on an Intel-based "cloud environment". And what's to say other similarly nasty vulns don't exist?
Oh, and Equifax comes to mind when I see this...
-
Now that every interrupt is going to be flagged, expect Intel to charge a toll.
-
I wonder if that's why my computers have been slow af the last few months.... wonder if they've already been releasing these updates.
-
@dangeruss Yes, and it's also been stealing your oxycontin from the medicine cabinet upstairs while you're asleep.
-
@blakeyrat said in Intel making us slow down:
@dangeruss Yes, and it's also been stealing your oxycontin from the medicine cabinet upstairs while you're asleep.
What makes you think I have any left after listing it on the silk road?
-
@dangeruss It's because your Intel chip runs a web server.
-
@pie_flavor said in Intel making us slow down:
@dangeruss It's because your Intel chip runs a web server.
I ed
-
You reverse-ninja'd me: https://what.thedailywtf.com/topic/24426/intel-bug
-
@dangeruss said in Intel making us slow down:
@pie_flavor said in Intel making us slow down:
@dangeruss It's because your Intel chip runs a web server.
I ed
-
This is a perfect excuse for a new PC :D My old one is already 3 years old. I think if I scavenge GPU from it, I might close within $600. The question is, how many dozen cores I need?
-
AMD only for 20 years
-
@gąska said in Intel making us slow down:
how many dozen cores I need?
Is that a legitimate thing yet?
-
@tsaukpaetra 1st gen Ryzen lineup has between 4 and 16 cores, 2 threads per core. I'm trying to decide between 6-core 1600 and 8-core 1700. So I exaggerated a bit, but it's still helluva lot of cores.
-
@pie_flavor The IME thing was already enough for me to never buy anything from Intel again
-
Being a bit curious, I browsed the related posts and articles a bit. Two things stand out:
- Apparently leaking information through speculative execution isn't a problem on AMD.
- This particular experiment on leaking information from speculative execution on Intel CPUs apparently didn't quite work out, but I wouldn't be surprised if somebody made the general idea of it work.
The patch (hiding the kernel memory mappings from user space) would prevent that kind of thing too, I think...
-
God dammit Intel.
-
@gąska said in Intel making us slow down:
This is a perfect excuse for a new PC :D My old one is already 3 years old. I think if I scavenge GPU from it, I might close within $600. The question is, how many dozen cores I need?
It's an excuse as good as any. But ... I'd wait for benchmarks. The proposed patches seem to screw up syscall performance, but you already minimize doing those if you want good performance (batching and whatnot). If you're doing tons of small IO and stuff, you might be fucked. If you can batch everything into a few large calls (i.e., a lot of rendering code) or even avoid syscalls all the way (pure computations), you might not notice too much.
-
-
-
@lolwhat I know you meant that as "dude, you were ninja'ed", but what came to mind was, "so, you're recommending that Krzanich absolve his dishonor through seppuku?"
-
As someone who's been researching Intel's security weaknesses for a few months now... I'm just blown away. It seems to me that the scope and impact of this is worse than the Pentium FDIV bug. And the PR hit is looking even worse. Is Intel really just this bad at making processors? Two critical vulnerabilities in their management plane in less than a year and now it turns out their speculative execution doesn't take general protection faults into account?! Unbelievable.
I'd say things are looking better for AMD -- Ryzen was already looking competitive, and there have been no salient CVEs against its management plane interface... but the keyword there is yet, I suppose. AMD needs to make sure its own house is in order if it wants to capitalize on this, because hostile actors are necessarily going to gravitate towards the dominant processors on the market -- whosever those may be.
-
@boomzilla said in Intel making us slow down:
The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI
So basically, it's not a "fix" for the bug, it's a workaround to stop the bug from having security consequences.
What I really really hope is that they only enable that workaround if the system has one of the bad processors. Otherwise the rest of the people will be taking a performance hit for no reason.
-
At this point, the
ARMMOS6502 is looking better and better.../me starting looking up prices for FPGAs and textbooks on Verilog
-
@anonymous234 said in Intel making us slow down:
What I really really hope is that they only enable that workaround if the system has one of the bad processors. Otherwise the rest of the people will be taking a performance hit for no reason.
From the Linux patches, supposedly yes, this is only enabled in the affected do processors. But considering it's like "everything before 2017"...
-
@anonymous234 said in Intel making us slow down:
What I really really hope is that they only enable that workaround if the system has one of the bad processors.
In the Linux kernel, it is enabled at any x86 that isn't AMD. It was all x86 before this (lkml.org link)
-
BRB, buying Intel puts...
-
Sigh. I guess I'll start evaluating architectural changes to reduce the number of syscalls....
-
-
@lolwhat Not at the moment. In fact, I wouldn't be surprised to see AMD fall when the news becomes public, and maybe NVIDIA, because they're in the same sector and that's how automated trading systems work, for better or for worse.
-
@cvi said in Intel making us slow down:
If you're doing tons of small IO and stuff, you might be fucked.
*coughc++programmingcough*
-
I'm sure none of the gummint TLAs 'sploited this vuln for anything. Right?
Nvidia GPUs exercise the CPU pretty heavily when doing draw calls...
Is the reason that AMD CPUs are slow relative to Intel's, that they actually check for a potential page fault before speculative execution of a given instruction? Did Intel use this cheat as a way to defraud people into choosing them over AMD, while covering up the massive security flaw?
-
@masonwheeler said in Intel making us slow down:
and that's how automated trading systems work
Surely this should mean an opportunity for human traders to steal some cash off those trading systems?
-
@gąska said in Intel making us slow down:
@cvi said in Intel making us slow down:
If you're doing tons of small IO and stuff, you might be fucked.
*coughc++programmingcough*
Uhh ... what?
-
@lolwhat Nah, I'll roll with incompetence as the root cause here.
I'll be switching back to AMD at home for the foreseeable future.
-
@anonymous234 said in Intel making us slow down:
Surely this should mean an opportunity for human traders to steal some cash off those trading systems?
Unlikely, unless you've got an even faster trading system.
Me I prefer to simply cash in on the near-certainty that Intel's stock will take a big hit when the news breaks. Simpler and safer that way.
-
@weng said in Intel making us slow down:
@lolwhat Nah, I'll roll with incompetence as the root cause here.
I'll be switching back to AMD at home for the foreseeable future.
Does this even affect home systems? (ie. do you and I have any real reason to be concerned about our home PCs?) From what I've read, it appears that this is an issue that's mostly a headache for cloud servers and other shared systems.)
-
@cvi said in Intel making us slow down:
@gąska said in Intel making us slow down:
@cvi said in Intel making us slow down:
If you're doing tons of small IO and stuff, you might be fucked.
*coughc++programmingcough*
Uhh ... what?
C++ compilers spend most of their time reading thousands of miniscule header files. Over and over again.
-
@masonwheeler said in Intel making us slow down:
@weng said in Intel making us slow down:
@lolwhat Nah, I'll roll with incompetence as the root cause here.
I'll be switching back to AMD at home for the foreseeable future.
Does this even affect home systems? (ie. do you and I have any real reason to be concerned about our home PCs?) From what I've read, it appears that this is an issue that's mostly a headache for cloud servers and other shared systems.)
When your OS gets updated your Intel machine will run more slowly.
-
@gąska said in Intel making us slow down:
@cvi said in Intel making us slow down:
@gąska said in Intel making us slow down:
@cvi said in Intel making us slow down:
If you're doing tons of small IO and stuff, you might be fucked.
*coughc++programmingcough*
Uhh ... what?
C++ compilers spend most of their time reading thousands of miniscule header files. Over and over again.
If you have enough memory it should only read them once each and then the file should be cached, though.
-
@boomzilla except the Unix Philosophy™ is to have make fire up a completely separate, completely isolated, cold-started instance of gcc for every .cpp file you have. I'm pretty sure it's the only working mode gcc and clang have, so changing build system can't help here. Visual C++ might be better in this regard, though I'm rather skeptical. The best you can do is precompiled header, but it can only get you so far.
-
@weng said in Intel making us slow down:
I'll roll with incompetence as the root cause
That's some Grandmaster-level incompetence for it to have been out in the wild for years and not to have it patched...
-
@anonymous234 said in Intel making us slow down:
@masonwheeler said in Intel making us slow down:
and that's how automated trading systems work
Surely this should mean an opportunity for human traders to steal some cash off those trading systems?
-
@boomzilla said in Intel making us slow down:
@masonwheeler said in Intel making us slow down:
@weng said in Intel making us slow down:
@lolwhat Nah, I'll roll with incompetence as the root cause here.
I'll be switching back to AMD at home for the foreseeable future.
Does this even affect home systems? (ie. do you and I have any real reason to be concerned about our home PCs?) From what I've read, it appears that this is an issue that's mostly a headache for cloud servers and other shared systems.)
When your OS gets updated your Intel machine will run more slowly.
So, business as usual for Windows?
-
@scholrlea Cue the Office Space clips...
-
@gąska said in Intel making us slow down:
@boomzilla except the Unix Philosophy™ is to have make fire up a completely separate, completely isolated, cold-started instance of gcc for every .cpp file you have. I'm pretty sure it's the only working mode gcc and clang have, so changing build system can't help here. Visual C++ might be better in this regard, though I'm rather skeptical. The best you can do is precompiled header, but it can only get you so far.
So what? The OS still caches files for you. I dunno, I guess that'd still be hit by the slowdown.
-
@gąska Yeah, OK, fair point.
@boomzilla said in Intel making us slow down:
So what? The OS still caches files for you. I dunno, I guess that'd still be hit by the slowdown.
You still use syscalls (open/read/stat/whatever) to access the data (even when it's cached by the system). The cost of each syscall is what increases. I'm guessing that the additional cost is fixed, so it's comparatively worse for short syscalls.
-
@boomzilla said in Intel making us slow down:
So what? The OS still caches files for you.
The OS will cache it, but each small will still be a syscall.
edit: damn ninjas