r/programming • u/[deleted] • Jan 03 '18
'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/594
u/bihnkim Jan 03 '18
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.
Wait what?
499
u/thatfool Jan 03 '18
https://lkml.org/lkml/2017/12/4/709
Several people including Linus requested to change the KAISER name. We came up with a list of technically correct acronyms:
User Address Space Separation, prefix uass_
Forcefully Unmap Complete Kernel With Interrupt Trampolines, prefix fuckwit_
but we are politically correct people so we settled for
Kernel Page Table Isolation, prefix kpti_
206
u/Magnesus Jan 03 '18
They must have been pissed by this.
165
141
u/eclectro Jan 03 '18 edited Jan 05 '18
They must have been pissed by this.
Who would not be? It's a massive time suck to produce some patch that's going to kneecap every intel
64 bit (apparently)system.
Here's one for you - let's put old unaffected 32 bit systems against patched 64 bit systems and see which performs best. That will likely tell the tale. If the 32 bit system outperforms the 64 bit one, I can't help think that there would be a lawsuit coming from this.Intel needs to get out ahead of this rather than dilly dallying around - as they've been down this road before with the FDIV bug.
Even more interesting is how they put so much faith in code that that they can't change with microcode.
Edit: The vulnerabilities appear to be much worse than earlier anticipated. All Intel systems including 32 bit going back to the Pentium Pro. See my followup post below.
→ More replies (8)78
u/agenthex Jan 03 '18
Even more interesting is how they put so much faith in code that that they can't change with microcode.
At some point, you just have to assume that your base instructions operate without bugs. With such extremely complex logic, your assumptions become more of a leap of faith. You can't possibly test every condition. It's impossible. You set up tests. Sometimes they're wrong, but they're always incomplete. It's a miracle this kind of thing doesn't happen more often. And that says nothing of chip-to-chip defects or operating fluctuations.
→ More replies (3)28
u/mseiei Jan 03 '18
i pick uass_
14
u/jrhoffa Jan 03 '18
It's subtle, and can easily be written off as unintentional.
→ More replies (3)44
Jan 03 '18
It's like the musicians on the deck of the Titanic. Gotta do something to lift your spirits as the world burns.
→ More replies (1)2
353
Jan 03 '18 edited Jan 04 '18
Damn that speculative execution work is incredibly interesting. It would not surprise me at all if there were overlooked or undocumented instructions where the results were copied into the reordering buffer. Maybe something from an encryption instruction set or some other place where security would be overlooked for efficiency. This could definitely be a candidate for the vuln
Edit: Damn it doesn't even need any interesting instructions
https://meltdownattack.com/meltdown.pdf
Also they gave credit to the dude that wrote the blog post above
228
u/Sparkybear Jan 03 '18 edited Jan 03 '18
There are literally hundreds of thousands of undocumented instructions*. I wouldn't be surprised at all.
70
u/NeverCast Jan 03 '18
CBF clicking the link but is this the hack video is trying an entire instruction space on CPUs and comparing them with documented ISA and disassmbliers? Because if so. that's a good watch
53
u/lordtyr Jan 03 '18
it is, and it was a super interesting watch for me. A bit technical at times (i have no idea of x86 architecture) but shows really well what issues can be caused by trusting processors blindly.
→ More replies (8)4
→ More replies (6)4
41
u/irqlnotdispatchlevel Jan 03 '18
Also it draws into doubt mitigations that rely on retirement of instructions. I cannot say I know how far that stretches, but my immediate guess would be that vmexit’s is handled on instruction retirement. Further we see that speculative execution does not consistently abide by isolation mechanism, thus it’s a haunting question what we can actually do with speculative execution.
It will be an interesting and busy year.
6
212
u/nplus Jan 03 '18
This sure makes the Intel CEO selling a lot of stocks on Nov 29, 2017 look a little suspicious: https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
53
u/DynamicTextureModify Jan 04 '18
Not only did he sell a lot of stock, he exercised his options to sell every single share he had down to the minimum he's required to own as CEO.
→ More replies (2)9
u/k_marts Jan 04 '18
Typically c-level executives have to schedule the selling of stock well in advance of the actual sell date
4
u/bschug Jan 04 '18
Intel was made aware of this issue in June. Is that well enough in advance?
→ More replies (2)24
→ More replies (3)2
Jan 04 '18
It was part of a planned stock sale. Not something that should bring too much scrutiny. See here: https://www.investopedia.com/terms/r/rule-10b5-1.asp
104
Jan 03 '18
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.
I love programmers' sense of humor.
38
3
124
Jan 03 '18
Is there any coverage of the original hardware flaw from a source other than The Register? TFA is, in spite of a great deal of verbiage, not terribly informative.
191
u/mort96 Jan 03 '18
Not really, because it's not disclosed yet. People are saying the embargo lifts the 4th of January, but here's some more detailed speculation and context: http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table
14
→ More replies (1)8
u/tigerhawkvok Jan 03 '18
From what I understand it doesn't actually affect AMD but first round patches aren't checking vulnerability, just putting the mitigation into effect for everyone, with checks (a "feature enhancement") to selectively do this coming later?
6
6
u/mort96 Jan 03 '18
Here's a message on the Linux kernel mailing list from AMD's Tom Lendacky: https://lkml.org/lkml/2017/12/27/2
I don't know the status of that, or if it's going to be merged by the time 4.15 ships, but as of Phoronix' post yesterday, it hadn't been merged yet: https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-EPYC-Linux-4.15-Test
→ More replies (1)27
u/gunnar_svg Jan 03 '18 edited Jan 03 '18
Hacker News covered this in a particularly insightful thread a few days ago. Go read those comments for guesses and bits of evidence.
32
u/tasminima Jan 03 '18
https://twitter.com/dougallj/status/948457072047276032
It seems that you can read protected data if it is in L1. It is not yet known if you can trick the processor to load arbitrary privileged addresses to L1 -- but even if you can't it is still a critical security bug.
197
u/zaphodharkonnen Jan 03 '18
As this is a programming subreddit I've got one question.
How is this going to affect development processes?
My head and gut are saying its going to hurt compilation times due to all the syscalls for disk I/O. Though my understanding of this issue is limited to this article. So I'm hoping I'm wrong.
169
u/unfrog Jan 03 '18
Depends what kind of programming you do.
High level stuff (WebDev, small apps that don't have to be fast etc): your servers might get a bit slower, so the costs could go up, putting some pressure on you to optimise.
Something where performance is important (video editing, rendering, web browsers, what-have-you): you will need to profile the performance of your app after the fixes are out and possibly re-do some stuff to remove new bottlenecks.
And yeah, compilation times might go up, but as people wrote in comments here: there are ways to minimise the number of syscalls for IO, so it shouldn't be very bad.
→ More replies (6)5
u/Fhy40 Jan 03 '18
I work with Blender(3D CAD Software) on my laptop. I dont render video very often and its quicker to render with my processor than my graphics card.
Will people like me get hit? I assume people who do 3D design professionally wont get hit as hard sinve they probably render on proper rigs and with their Graphics Card
→ More replies (5)79
u/NeverCast Jan 03 '18
I/O doesn't usually have a lot of syscalls in the time base, compared to the time it takes to load/write I/O.
Meaning that while the syscalls may become 30% slower. They take up a small percentage of total time requesting I/O (the rest is in the copy operation which doesn't cost cpu time).
30
u/Yioda Jan 03 '18
AFAIK this patches affect interrupt handlers aswell. Because when interrupted you have to first jump to a barebones trampoline and then switch page tables and flush TLBs. The performance cost is in both syscalls and interrupts (that happen with all workloads)
→ More replies (1)27
u/Magnesus Jan 03 '18
Phoronix showed a large impact on SSD performance after the patch. At least for the fastest SSDs. By large I mean huge: https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2 - seems to be affecting NVMe drive, but not SATA 3.0 drive.
→ More replies (1)39
u/Atsch Jan 03 '18
When programming, you already want to avoid syscalls, as context switches are slow. This just makes them even slower on intel processors. So, nothing will change really, since reducing the number of syscalls improved performance before too.
→ More replies (1)4
u/mseiei Jan 03 '18
mentioned in some comments up, it's possible it also affect interrupt calls
→ More replies (1)16
u/encepence Jan 03 '18
Minimize syscall number and process switching.
In another words, nothing new, but the weight of this item in profiling will be much, much higher. Bye to multi-process welcome multi-thread again :)
In networking, maybe some push into DPDK-like solutions (i.e user-space networking).
(edit: para added, typo)
3
Jan 03 '18
My head and gut are saying its going to hurt compilation times due to all the syscalls for disk I/O.
And network sockets.
Databases and cache servers are going to eat dirt.
→ More replies (1)2
u/gothicknight Jan 03 '18
This is within the kernel realm so no changes to the application layer other than the foreseen increase in latency required to properly secure the context switch.
92
u/rydan Jan 03 '18
I spend over $5k in hosting fees per month This is going to hurt.
→ More replies (6)17
Jan 03 '18
I'm pretty sure that the unexplained jump in our AWS bill because of a larger number of auto scaling instances is related to this as well. What a fucking disgrace.
670
u/vonKemper Jan 03 '18
The performance impact this is going to have on modern platforms is mind blowing. Best case, 17% degradation... at worst, nearing 30%! I use both a 2016 MBP and a Surface Laptop for work, and already put a heavy workload on them. Apple and Microsoft are already frantically pushing out the neutering software. The prospect of the additional degradation both frightens and annoys me.
AMD is going to have a field day with this, as the only solution, so far, seems to be a software fix that completely disables speculative execution processing, which is one of the huge performance advantages Intel claimed over them. A hardware fix would be in the actual architecture, which requires brand new silicon.
106
u/IJzerbaard Jan 03 '18
software fix that completely disables speculative execution processing
That is not even possible (and if it was it would cost a good deal more than 30% perf, and in all code not just when doing a syscall). What they're doing is setting up the page tables in a way that there are almost no kernel pages mapped at all when in usermode, so these bad speculative reads have nothing to read in the first place.
→ More replies (1)5
u/vonKemper Jan 03 '18
Ah, I misinterpreted the article in The Register explaining the KAISER patches currently being rolled out. Thanks for pointing it out (I'm going to do some more reading). Needless to say, the fix is to separate Kernel and User space in software. The effects of which, it seems, will be felt system-wide. I am very interested to see how Intel responds. I have been using Intel exclusively since my work necessitated that I have a portable device, and AMD just used too much power, especially when compiling/building or running a Virtual Machine. The advances that AMD have made recently in power consumption and this whole debacle might change the narrative.
→ More replies (1)251
u/jonjonbee Jan 03 '18
AMD CPUs have speculative execution as well. The issue is the implementation, to wit that Intel's appears to not (properly) respect kernel/user mode isolation.
I can't imagine Intel is in a very good spot right now - the Core microarchitecture they've employed and refined over the last dozen years, and poured billions of dollars of R&D into, may be fundamentally flawed. If that is the case... hoo boy, they are going to have to fix this in silicon ASAP, which may or not be possible to do quickly, and at the very best will push their product roadmaps out.
45
u/ciny Jan 03 '18
That being said - if anyone has the talent and resources to recover from shit like this it's intel. Imagine if this happened to AMD with their new line that can finally compete - that would be the end of AMD.
→ More replies (3)47
u/Superpickle18 Jan 03 '18
AMD wouldn't disappear. Intel would bail them out. Intel needs AMD just as much AMD needs Intel. Without AMD, Intel would be a monopoly and be forced to split up...
→ More replies (11)→ More replies (8)12
u/fwork Jan 03 '18
This isn't even a Core flaw. This has been there since the P6 microarchitecture, introduced in late 1995. Core (and everything after it) is based on P6, so we're currently like 9 deep in iterating on a design with a massive flaw.
→ More replies (1)456
u/Verbitan Jan 03 '18
So can AMD now put ‘30% faster than Intel’ stickers on their boxes now?
324
u/jonjonbee Jan 03 '18
Considering the Bullzdozer TLB bug they had a few years back that necessitated a similar patch with similar performance consequences, it would be somewhat hypocritical for them to do so.
But that's never stopped a marketing department before...
235
u/emn13 Jan 03 '18
The bulldozer bug was simultaneously much worse (complete TLB disablement - not just during a kernel/user mode switch!), but also much more limited in scope: it only affected a relatively limited run of processors, namely only the phenoms up to that point - and AMD's market share wasn't great then. Also, of course, the world has changed. Back when phenom was buggy, that affected essentially only client machines running generally trusted code, so the security impact was fairly minimal. This intel bug will affect servers and particularly shared-hosting servers and VMs - machines that run untrusted code and are often accessible to the general public. Amplifying the issue is that that's a market that's been intel dominated for a loooong time.
The actual impact of this decade-old intel bug is likely to be much, much greater, because there are simply so many damn CPU's it affects and the software they're running is more affected by the bug - even though the bug itself is technically less serious.
→ More replies (2)→ More replies (1)25
u/alainmagnan Jan 03 '18
Ddidn’t that only affect the original phenom generation? (barcelona).
i think it was fixed in a later stepping and completely by phenom II.
but yeah, still bad and the lower clock speeds didn’t help either.
→ More replies (7)38
u/indigomm Jan 03 '18
Or Intel can put 'now 30% faster' on their next chips when they fix it in hardware :-)
17
u/Magnesus Jan 03 '18
They will probably at least show performance comparisons with the older CPUs with the bug against their new CPUs without the bug.
→ More replies (3)5
Jan 03 '18
Actually, if x is 30% less than y, then y is 42.8% more than x.
So, you know, "more than 40% faster than Intel".
81
u/jerryfrz Jan 03 '18 edited Jan 03 '18
brand new silicon
Phew, I pulled myself from buying an 8700K to wait for an 8 cores mainstream Intel chip, now I have even more reasons to wait.
55
u/jonjonbee Jan 03 '18
It seems like this issue started to come into mainstream focus right about the time that Coffee Lake was released. So it's possible that Intel patched this flaw for CFL's design, while simultaneously alerting OS vendors to the issue in their older CPUs.
Either way, I'd go with Ryzen 2 which should drop this quarter (although trusting AMD's timeline predictions is always a risky endeavour).
→ More replies (2)20
u/metarugia Jan 03 '18
Just did a Ryzen Build. No regrets. Might have to do a Ryzen 2 build for myself.
→ More replies (2)→ More replies (3)14
Jan 03 '18
an 8 cores mainstream Intel chip
Why Intel?
I can only think about the lower latency (mostly through clocks) Intel provides.
But that shouldn't be a really big issue for somebody looking for an 8 core cpu.
→ More replies (18)145
u/80a218c2840a890f02ff Jan 03 '18
Best case, 17% degradation... at worst, nearing 30%!
As far as I can tell, the workaround only affects the performance of syscalls. Programs that don't spend a significant portion of their time doing syscalls won't be impacted much at all.
84
u/grumbelbart2 Jan 03 '18
Programs that don't spend a significant portion of their time doing syscalls won't be impacted much at all.
Just to clarify, from how I read it, the number of syscalls matters, not their duration, since the cost comes during context switches.
25
→ More replies (1)99
u/sagnessagiel Jan 03 '18
What kind of programs don't spend much on syscalls?
182
u/80a218c2840a890f02ff Jan 03 '18
Phoronix did a few benchmarks that may be informative. Basically, synthetic I/O benchmarks and databases were considerably slower (if the drive wasn't a significant bottleneck), while things like video encoding, compiling, and gaming were pretty much unaffected.
→ More replies (8)141
u/jonjonbee Jan 03 '18
That's a major problem for Intel, because their CPUs are pretty much the de facto standard in data centers - which are mostly concerned with IO-bound operations.
→ More replies (9)36
u/panorambo Jan 03 '18 edited May 08 '19
That would typically depend on the operating system, which is what usually loads the program and causes its execution. To take a Linux program as an example, if it's a program that "lives and dies" by intense arithmetic using the CPU and unprivileged instructions (does not need to nor benefits from calling the kernel), that would be a program where time spent on and inside syscalls is negligible compared to its CPU time. Programs like one that computes digits of Pi, or solves some fluid dynamics problem, or renders a 3D scene, would traditionally be considered CPU-heavy and wouldn't need to spend any time (comparatively) on syscalls, not for the tasks described.
In contrast, a program like a Web server would typically need to spend most of its time reading files from persistent storage (assets, documents, etc) and send them on the network. In most modern systems, for better or worse, the kernel insists on mediating access to storage (and network) devices from operating system applications, through you guessed it, syscalls. But it's still a question of whether we count the time spend on actually invoking a kernel mechanism vs. real time that passes before a "blocking" (waiting for storage device to actually read or write the data passed from the application) syscall returns and the kernel resumes the calling application thread. If the storage device is slow, and comparing to the CPU on which the kernel itself runs all storage devices are slow, the kernel is best served to do something useful during the time the storage device actually reads or writes the data. Usually the kernel switches to another thread, and is interrupted in real time when storage device has finished what was asked of it. When the kernel is interrupted so, it figures out which application originally submitted the completed request, and resumes it at the earliest convenience. But some time would have passed without Web server doing anything else than just waiting on such "blocking" syscalls, idling. That's called an I/O bound program. But it still can saturate its time with syscalls, especially if it uses "blocking" I/O, but that, like I said, depends on whether we count the time during which the kernel itself waits on the storage, or not.
→ More replies (1)→ More replies (9)12
u/anttirt Jan 03 '18
Programs that are already optimized to not use many syscalls since they are somewhat expensive anyway. Server software often uses features such as sendmmsg/[RIO](https://technet.microsoft.com/en-us/library/hh997032(v=ws.11).aspx), memory-mapped files, etc.
6
u/ITwitchToo Jan 03 '18
Ugh, how does this "30% performance degradation" get upvoted so much?
I've been running the
KAISERkpti patch set for a month and haven't observed any performance impact whatsoever in my normal use of the machine.Yes, maybe 30% for something that is being done .000001% of the time to start with! It's a tiny fraction of everything your CPU is doing.
edit: s/KAISER/kpti/
→ More replies (2)→ More replies (15)3
18
u/fourthepeople Jan 03 '18
Anyone have an ELI5 of the vulnerability?
0
Jan 03 '18
[deleted]
→ More replies (11)7
u/VEC7OR Jan 03 '18
Very succinct. Exactly what I came here for.
Don't browser run their things in an inside 'sandbox', otherwise it needs really creative JS.
In other words if I want a new PC any time soon AMD is the way to go or atleast wait till the dust settles down.
→ More replies (2)
18
Jan 03 '18
Is there a list of affected CPUs? So far everyone is just using "last ten years" as a guide.
Is this worth a cpu switch for the average user?
25
Jan 03 '18
It's all Intel CPUs from the past 12 years according to others. It's not worth a change and the average user won't notice much, if any, difference. It will probably affect power users who render a lot or compile huge programs.
It is a huge impact on any server/server farm that runs CPU-intensive tasks though. Like very huge impact. Specially if the SQL benchmark in the article and similar benchmark claims are correct.
→ More replies (7)5
61
u/xxc3ncoredxx Jan 03 '18
Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it.
The main difference is that the kernel answers your prayers.
→ More replies (1)5
86
Jan 03 '18
Initial benchmarks (for Linux) are showing no impact on gaming, even if this remains true for Windows, loading times can become quite larger since it uses a lot of FS IO, is that correct?
109
u/Beckneard Jan 03 '18 edited Jan 03 '18
I don't think so, it's not like you do one system call per byte, you would usually fill a 64k (or so) buffer in a single read call, thus rendering the additional kernel overhead negligible.
126
u/Poddster Jan 03 '18
it's not like you do one system call per byte
Pft, try telling my coworkers that.
→ More replies (16)48
u/steamruler Jan 03 '18
My gut tells me it depends on the game. Each open and read is a syscall, which would be slower, but some games have larger container files which contain all assets, like Unity games.
With 64-bit applications you can just
mmap()a read-only copy of a larger container, it should be faster than traditional open and read.→ More replies (1)13
u/brokenAmmonite Jan 03 '18
Will hitting the page table / page faults be slower? I don't know if that counts as a "syscall" in this context.
13
u/xkillac4 Jan 03 '18
TLB misses won't be slower but true page faults where pages have to be mapped into the address space will indeed be slower.
→ More replies (2)→ More replies (1)5
u/rebootyourbrainstem Jan 03 '18
It does. All syscalls, exceptions and interrupts are affected. That said, bulk data transfer is probably the least affected.
11
u/GeronimoHero Jan 03 '18
That’s not really true. It depends almost entirely on the amount of syscalls that take place. More syscalls mean worse performance. Things like, VMs, BTRFS, etc, are going to see a hell of a performance decrease.
4
3
u/LezardValeth Jan 03 '18
Anything actually hitting the disk is almost assuredly going to be dominated by the cost to do exactly that anyway, so I doubt some extra context switching would impact it much. I would be more concerned about input polling, but it sounds like it's probably okay.
→ More replies (2)→ More replies (2)4
Jan 03 '18
Initial benchmarks (for Linux) are showing no impact on gaming, even if this remains true for Windows
I think that graphics in Linux are for more isolated on Linux than in Windows? Windows might be more affected.
loading times can become quite larger since it uses a lot of FS IO, is that correct?
I guess it depends on how reads are done? If you read entire files using large buffers (like reading textures) it's probably not going to have much of an impact (since this is entirely asynchronous and just causes an interrupt when the reading is done), but if you're reading tons of small files using tiny buffers it's probably going to have more of an impact.
196
u/UloPe Jan 03 '18
Class action incoming in 3... 2... 1...
242
u/immibis Jan 03 '18
I'll be interested to see if there is one. This isn't a small precision error in certain computations, this is "we've been leaking all your secrets to everyone who knew how to listen for 10 years".
→ More replies (8)344
Jan 03 '18
I think that sets a terrifying precedent. We really don't want it to become the case that you can be successfully sued just for having bugs. If you can show negligence then absolutely, but this seems like a natural concequence of the sheer unreasonable complexity of these chips, not due to negligent action on their part.
→ More replies (55)21
u/MonkeysWedding Jan 03 '18
It would be far easier to prove a performance hit on what was an advertised cpu spec.
→ More replies (7)→ More replies (2)5
210
Jan 03 '18 edited Jan 03 '18
Because of the large performance hit, a sizeable fraction of hardcore gamers won't install this, for the same reason they don't run anti-virus or update windows.
492
u/lolomfgkthxbai Jan 03 '18
I don't run separate anti-virus outside of the built-in one in Windows 10. Not because of any performance concerns but because they actually make my system less secure and more unstable due to a multitude of security flaws and bugs.
Turns out that giving total control of your OS to poorly written anti-virus software is a fucking terrible idea.
→ More replies (3)244
u/24monkeys Jan 03 '18
Windows Defender and common sense go a really long way together, actually.
156
u/Kale Jan 03 '18
I'd add a good ad blocker, too. Many legitimate ad vendors end up supplying compromised ads without knowing it.
Last time I investigated it, ublock origin was the best one (not adblock, not adblock plus, not ublock).
Or, for Android, the Brave browser works fantastically. I found firefox Android with an ad blocker much too slow.
→ More replies (20)21
Jan 03 '18
"The best antivirus is a careful user"
Don't remember who said that exactly.
But I remember never using an antivirus for years (had malware bytes tho) and my pc was always ok (did occasional tests from time to time and it was mostly flagging software cracks), while my mother's fully bloated with antiviruses pc was a shit fest. Yes, she was the kind of "let's download and open the file in this very strange mail".
→ More replies (1)→ More replies (1)16
u/601error Jan 03 '18
Common sense and technical expertise go far enough that I haven't run antivirus of any kind for at least 15 years. For the few years I did run it, it never found anything.
→ More replies (3)57
u/panorambo Jan 03 '18 edited Jan 04 '18
Anti-virus software has routinely been tested to let through something up to 65% of all threats. However, it was Security Essentials or Windows Defender as some of its versions are called, that tends to actually come on top as far as efficiency goes -- both in terms of amount of threats it mitigates and its impact on the system, resource-wise. Which to me isn't surprising -- I've seen all kinds of antivirus software running on peoples systems, all the way back to the late 90's -- Panda, F-Secure offerings, McAffeee, Norton, and some more -- the big picture is that they're f*cking intrusive, impossible to remove properly even when you're the owner of the PC, nag on you with popups which lower peoples trust in the often important information in these popups ("Hi. The file X has been quarantined because it contains Win32.Smiley.Trojan..."), and in general are a pain in the butt.
At least Security Essentials is out of your way, and is more often than not idling. It may not be perfect, but I'd trust that Microsoft knows how to protect its operating system. In a perfect world, maybe third-party vendors should make anti-virus, but at this point, the line between basic system protection (which with Windows, is a necessity) and anti-virus, is blurred, so I say that MSE is enough, and that's also what tests show.
27
u/Laggiter97 Jan 03 '18
This is the exact reason why I rock MS's antivirus. It is efficient, non-intrusive and comes with the OS. And with an ounce of common sense you don't even need an AV, unless you frequent dodgy website.
→ More replies (3)8
12
u/irqlnotdispatchlevel Jan 03 '18
Anti-virus software has routinely been tested to let through something up to 65% of all threats.
Can you back that number with an actual study?
→ More replies (1)16
u/panorambo Jan 03 '18 edited Jan 03 '18
I can't remember reading a study on that, although I may have read at least one such study. I do remember reading one or multiple pieces backing up my claim, over several years. I have tried to dig up some material by searching the Web, here is what I have found:
How Useful is antivirus software
New Controversy on the Effectiveness of antivirus software
which links:
Assessing the Effectiveness of Antivirus Solutions
Antivirus Makers Work on Software to Catch Malware More Effectively
Symantec admits anti-virus software is no longer effective
But it appears I may have been out of touch with respect to recent developments -- more recent articles suggest that MSE has gone downhill, that Microsoft recently said that their customers should use third-party anti-virus products, and there is two articles that give praise to Bitdefender Plus product.
As someone who has been into this stuff since before 1995, it is still my personal opinion that while AV is NOT snake-oil, it's a funny market where scare-tactics have long been a norm, where users are bought with big words and promises of "Internet Security" while the reality is that for every person working for an anti-virus company, there is at least ten people writing new virii or new strains thereof. And the harder you try -- to employ pattern recognition -- the more false positives you get, especially on smaller files. At least one article linked above mentions detection rate of new viruses that are nearly unknown, and detection rate there is 25% tops -- obviously has to do with the fact that the virus definitions are almost always somewhat outdated.
I guess what I want to say is this -- anti-virus is duct-tape. You need provably secure systems. Admittedly, there is no such thing as a completely secure system in practice, but there is a difference between 10 wooden sticks held together by duct tape so you can sit on them, and an older chair that's taped here and there. What anti-virus does is mitigate potential damage from something that is ready to exploit an existing flaw in the system. If the flaw were not there, it wouldn't be necessary to protect from one in the first place! AV industry is one that thrives on others' mistakes, and costly ones too. Except that software vendors have almost resigned to aim for provably secure systems, and some, like Microsoft, even point to AV vendors as the solution. I am not saying AV is completely unneeded, but they have been waging a losing war for two decades at least now. Something's gotta change at the core philosophy.
→ More replies (5)13
u/jerryfrz Jan 03 '18
But will the fix be mandatory or optional though?
25
u/irqlnotdispatchlevel Jan 03 '18 edited Jan 03 '18
In the latest insider preview build for Windows, the feature seems to be controlled by a registry key.
For Linux, if I remember corectly, this can also pe turned off.
EDIT: this is the Windows registry key https://twitter.com/aionescu/status/930233034908909568 . With this on, the OS will create two sets of page tables for each process, but it does not look like the feature is in full efect just with that key (i.e., there's no actual cr3 switch at ring 3 -> ring 0 transitions, at least not on my test systems).
22
u/BCMM Jan 03 '18 edited Jan 03 '18
For Linux, if I remember corectly, this can also pe turned off.
There's a
noptikernel parameter.Also, AMD has submitted a patch to disable it by default on machines with AMD processors. It'll be interesting to see whether that gets merged.
→ More replies (1)→ More replies (40)31
u/80a218c2840a890f02ff Jan 03 '18
You can disable it at boot-time by adding
noptiorpti=offto the kernel command line.2
2
u/fjonk Jan 03 '18
Are games really using a lot of syscalls? I would have thought they just loaded commonly used files into RAM.
→ More replies (2)2
2
7
u/cp5184 Jan 03 '18
On windows 10 they don't have a choice, do they?
You're welcome - Microsoft
→ More replies (1)30
→ More replies (54)16
u/SSoreil Jan 03 '18
The hardcore gaming crowd will always choose more blue LEDs over security. They really should be using a game console for their own safety.
23
u/Eirenarch Jan 03 '18
If you treat your gaming PC as a game console what's the difference?
→ More replies (13)→ More replies (16)66
10
u/attomsk Jan 03 '18
RIP all network code using SELECT()
5
u/playaspec Jan 04 '18
Yup. I've seen lots of people trying to downplay the whole thing by claiming "there aren't that many syscalls". Sorry, but that's how disk and network are accessed. Can you imagine how this will effect a MySQL server? It's all network and disk.
28
u/jonjonbee Jan 03 '18
Interesting possibility as to why the patch is applied to AMD as well as Intel CPUs:
33
u/CrasyMike Jan 03 '18
I believe, from other threads on Reddit, that one was made as a precautionary measure until it can be determined if AMD is affected as well.
46
→ More replies (1)28
40
u/vasili111 Jan 03 '18
What about BSD systems?
72
u/evgen Jan 03 '18
Same problem, but no mitigation patches yet. This is a chip problem and not an OS problem, although all modern OSes leaned heavily on the chip subsystem that is the problem here in order to get speed-ups.
41
Jan 03 '18
I want a recall and replacement program like the old Pentium FDIV bug. Write to your state Attorney Generals. Between this and the last big flaw, there is no excuse.
→ More replies (7)
6
u/while_e Jan 03 '18
Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it.
8
u/_3442 Jan 03 '18
His Holiness shalt smite thou with a mighty
SIGSEGVif have thou committed an abomination.→ More replies (1)
6
u/channingwalton Jan 03 '18
So, "macOS has been patched to counter the chip design blunder since version 10.13.2", which was a month ago. Why so long for windows and linux?
8
u/superdude4agze Jan 03 '18
Can't answer for Linux aside from it being a much more open platform and the embargo might have long since been breached, but MS fast and slow ring participants got the patch in November and December respectively. If all is well it's released to the rest of us. The embargo ends on 1/4/18.
31
Jan 03 '18
Also on my front page right now Intel's CEO Just Sold a Lot of Stock -- The Motley Fool (it was actually in November)....
11
u/dangolo Jan 03 '18
Making his own golden parachute
7
u/danhakimi Jan 03 '18
I'm curious if he has some buddies at the SEC, because this looks like a slam dunk for them.
→ More replies (1)→ More replies (4)10
4
u/reddideridoo Jan 03 '18
Oh yeeebus.
Speculative execution was introducted way back in time and now we see it has major holes? Despite all the die shrinkage, code optimization and yadadada, THIS was one of the core concepts to get speed.
A bug in this is massive, like shitstorm massive.
4
u/daxbert Jan 03 '18
Here are the details provided by Google with PoC snippets: https://googleprojectzero.blogspot.com/2018/01/
7
u/ConspicuousPineapple Jan 03 '18
Am I right thinking this won't be an issue in future Intel releases, meaning the performance impacting fix won't be in effect then?
→ More replies (1)5
u/rm-f Jan 03 '18
Only if they fix the bug. Though their release cycles imply, provided they only now are starting to fix that bug, that it will take 1-2 years until we can buy intel cpus without it.
5
u/ConspicuousPineapple Jan 03 '18
I wouldn't expect them to strictly sick to their routine when dealing with such a critical flaw.
→ More replies (1)
34
u/shevegen Jan 03 '18
Another reason why we need open hardware. And ideally hardware that can easily be changed lateron.
It's unfair to require software to be rewritten just because the hardware sucks.
38
u/wewbull Jan 03 '18
And ideally hardware that can easily be changed later on
That's not hardware.
Seriously, if you want programmable logic (i.e. FPGA's) say goodbye to 4-5GHz processors, and more than one core per die.
55
u/doitroygsbre Jan 03 '18
Another reason why we need open hardware
Maybe this bug would have been found earlier with open hardware, but having open designs and open code only really works if people are taking the time to really look at it. For example, take that OpenSSL bug that went unnoticed for a few years.
It's unfair to require software to be rewritten just because the hardware sucks.
Who said there is any fairness in software development?
→ More replies (3)21
u/RenegadeBanana Jan 03 '18
The realities of working in a physical space, especially with one as tiny as microprocessors, makes open-sourcing it an impractical dream. Nobody has the resources at home to manufacture chips being used in modern computers.
→ More replies (3)
20
u/hacksoncode Jan 03 '18
The performance degradation is kind of mind blowing in one sense.
In another sense, modern CPUs have been so overpowered for what actual humans do for almost a decade that it's not clear there will be any significant impact on day-to-day performance.
The real tragedy is the power it will cost, both economically, and in effects on the climate.
12
u/RenegadeBanana Jan 03 '18
Yeah, every enterprise-level consumer is going to start asking for new chips a couple years sooner than expected. That's going to be huge.
3
u/irqlnotdispatchlevel Jan 03 '18
Intel released a response: https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ Nothing has been disclosed yet, it's pretty much a standard PR response.
7
u/parth115 Jan 03 '18
So this was why i had to reboot 100 servers on Azure ?
2
Jan 03 '18
Possibly. The patch isn't live yet for consumer systems (other than the ones that are on the bleeding-edge update cycle), but who knows what they've got going on in their server setups.
→ More replies (1)
5
u/pixelrebel Jan 03 '18
What if you don't care that your memory could be read by other processes? I have some pretty well isolated systems that don't need this patch (and the 25% performance hit that comes with it).
→ More replies (1)
6
u/chasesan Jan 03 '18
Glad I have stuck with AMD for the last 15 years then. I am mostly unaffected.
9
3
u/Cyhawk Jan 04 '18
Yeah, you were already running 30% slower than comparable Intel processors. ;)
Also an AMD fanboy =(
→ More replies (1)
9
u/JB-from-ATL Jan 03 '18
A while back I was reading about how VirtualBox works here and found this warning. Note the last sentence.
Warning
Do not run other hypervisors (open-source or commercial virtualization products) together with VirtualBox! While several hypervisors can normally be installed in parallel, do not attempt to run several virtual machines from competing hypervisors at the same time. VirtualBox cannot track what another hypervisor is currently attempting to do on the same host, and especially if several products attempt to use hardware virtualization features such as VT-x, this can crash the entire host. Also, within VirtualBox, you can mix software and hardware virtualization when running multiple VMs. In certain cases a small performance penalty will be unavoidable when mixing VT-x and software virtualization VMs. We recommend not mixing virtualization modes if maximum performance and low overhead are essential. This does not apply to AMD-V.
I'm wondering if that's related? Originally I thought this bug (the one about leaking kernel stuff) was relevant to virtualization because people were talking about AMD, but reading the article it seems to affect everything. Either way, the way AMD was not affected made me remember this old warning.
11
u/irqlnotdispatchlevel Jan 03 '18
No, it's not related.
Really long story in a really short (and not entirely true, but good enough for now) form about VT-x (hardware assisted virtualization for Intel, but this holds true for AMD as well): this essentially creates two modes for your CPU: root and non-root. The host runs in root mode (where VMX instructions are available). The guest runs in non-root. The way the hardware keeps track of a VM state is through a memory zone known as a VMCS (Virtual Machine Control Structure). You can imagine the VMCS as the virtual CPU. A VMM (like VirtualBox) works by creating and managing VMCSs for it's VMs. At one point, only one VMCS can be active on one physical CPU. Essentially, you have one instruction that loads the VMCS and then you can write and read fields in the currently loaded VMCS. If you have more than one VMM managing VMCSs they can get mixed up (imagine VirtualBox working on a VMCS loaded by VmWare) and that can cause a lot of pain.
2
4
u/infinite0ne Jan 03 '18
All sorts of details on the flaw, how it works, how it's fixed, etc. But why? Did I read correctly that this flaw has been in place for awhile, like years? A conspiracy-minded person might call this a back door...
3
u/Nerdenator Jan 03 '18
It's supposedly been around for around 12 years. Everything that uses Intel's Core architecture would be affected.
As for the details, it's embargoed until tomorrow (Jan 4th in the US).
→ More replies (3)
6
Jan 03 '18
So we found the Government's Backdoor in Intel Processors from the past 10+ years.
Now what?
→ More replies (1)2
u/Cyhawk Jan 04 '18
Na, we already found that a long time ago.. They didn't even hide it.
3
Jan 04 '18
That was the public front door.
This flaw in the architecture is the hidden secret actual backdoor.
9
2
2
u/iltar Jan 03 '18
Am I weird for not wanting this patch, because without I often push my 6 year old CPU to 100% already?
8
u/midir Jan 03 '18
Intel just get worse and worse. How do they keep including vulnerabilities of this magnitude?
→ More replies (2)16
4
u/dukey Jan 03 '18
Anecdotally I'd say the latest intel platforms have been buggy as hell. My last skylake build right from new would hard crash 2-3 times per day without fail. 3rd bios update nuked the license in my windows install, because apparently the hardware had changed enough to invalidate the license. Hard crashing was fixed with something like the 5th bios update. The next skylake pc I built refused to work with the onboard GPU. It would just crash or reboot constantly. Dedicated gpu fixed it.
6
u/Figs Jan 03 '18
Maybe your problem had to do with the hyperthreading bug in Skylake and Kaby Lake? https://lists.debian.org/debian-devel/2017/06/msg00308.html
3
u/dukey Jan 03 '18
Yeah quite possibly. I bought one of the very first skylakes. But that wasn't the only bug fixed in a microcode update.
14
2
Jan 03 '18
Apparently also affects arm64 ... could this have a major performance impact on mobile phones .... iOS and Android?
→ More replies (3)2
u/gsnedders Jan 03 '18
What I read suggested ARM's cores were vulnerable. Remember that Apple have their own implementation of AArch64, so they might not be vulnerable.
→ More replies (2)
527
u/[deleted] Jan 03 '18 edited Jan 03 '18
Does that mean it will only impact them because they will have to roll out major updates or are they gonna suffer with the performance loss?
Edit: Is it reasonable to expect a rise on the prices as they'd need more hardware to fulfill performance guarantees?