Last week the technology industry and many of our customers learned of new vulnerabilities in the hardware chips that power phones, PCs and servers. We (and others in the industry) had learned of this vulnerability under nondisclosure agreement several months ago and immediately began developing engineering mitigations and updating our cloud infrastructure. In this blog, I’ll describe the discovered vulnerabilities as clearly as I can, discuss what customers can do to help keep themselves safe, and share what we’ve learned so far about performance impacts.
The basic gist here is this: the older your processor and the older your Windows version, the bigger the performance impact will be. Windows 10 users will experience a smaller performance impact than Windows 7 and 8 users, and anyone running Haswell or older processors will experience a bigger impact than users of newer processors.
I really wish they had given more data. Other parties have provided benchmarks:
https://www.techspot.com/article/1556-meltdown-and-spectre-cpu-perfo…
As expected, IO intensive workloads incur the highest penalties for invoking frequent syscalls while CPU-bound processes that don’t cross the effected code paths incur almost none at all. For IO bound processes like databases with random access, the performance is just abysmal.
I have not found any studies that actually compare performance between CPU generations, the ones above were for a brand new system. Microsoft says:
Again, no data; I’d prefer to be shown, rather than being told. Anyways, from the vague information we’ve got about intel’s patch, it seems that they were able to disable speculative execution specifically for indirect references. Indirection is a crucial component of many object oriented languages like C++, disabling it shouldn’t effect windows and linux that much, but I’m very curious how well polymorphic code scores under intel’s patch? Alas, all my computers are too old to be supported by intel’s patch so I cannot test it.
Obviously it bricks AMD based computers. At least no more attack vector :
https://betanews.com/2018/01/08/microsoft-meltdown-spectre-patch-bri…
Windows has been migrating to C++ since Windows 8, after Longhorn’s failure COM took the OO ideas behind it, and it became the foundation of WinRT and .NET Native.
As of Vista, Visual C++ can target kernel code as well.
C compatibility on Windows is basically left to whatever is required from ANSI C++
moondevil,
I haven’t been involved with windows kernel development since windows xp, which is the last version where owners were allowed to build their own drivers for their own computers. I can say that C++ code never gave me much trouble in the windows xp kernel too (with the exception of exceptions, haha). C++ exceptions work differently than SEH (structured exception handlers) that the windows kernel uses.
Intel’s been very sparse on details, but I would guess the intel CPU update affect indirection performance system-wide, rather than just in vulnerable kernel code. The big question is just how much it slows it down. You may be right about COM and .net being affected as well, but I can’t test any of these since intel hasn’t released any updates for my intel CPUs.
Edited 2018-01-10 13:24 UTC
Here is an updated description from a Windows kernel team member at Reddit.
https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_coded_in_c_o…
Why did I get the idea Microsoft is making Windows 7 and 8 slower on purpose to make sure people move to Windows 10.
Why would Windows 7 or 8 be slower than Windows 10 for this ?
That is the part 1 I did not see addressed in the blog post.
Part 2 is: are they enabling that for all CPUs or all x86/AMD64 CPUs or only Intel CPUs ?
Edited 2018-01-10 11:16 UTC
Is it because you’re a paranoid douchebag?
Based on Microsoft’s tactics to get people to upgrade to Windows 10 over the past two years, I would say that just because they’re paranoid doesn’t mean they’re wrong.
Microsoft has approximately zero credibility when it comes to pushing Windows 10 upgrade paths.
I ‘discovered’ something terrible the other day. As anyone here is probably aware, with Windows 10 Pro or higher, you can set a registry setting to allow the group policy to switch off automatic updates.
The terrible thing is that things like Windows Defender is also tied to Windows Updates, so if you want newer definitions, you have to run your updates anyhow…
Lennie,
I’d like to know too. Also, I’d like to know if microsoft intends to make the changes permanent even as new intel processors come out that don’t speculate across security boundaries?
… that older version of Windows get a bigger hit. I was going to call it BS, thinking they could be adding some extra “spice” to favor upgrades. However, on the blog entry they actually explain why (and at least to me, it makes sense).
They should explain the hiccup with AMD processors (I hope it is not related to the Meltdown fix that in theory didn’t affect them).
The hiccup with AMD is that there are three variants of the speculation bug: Specter variant 1 and 2 affect all processors, not just Intel; Meltdown variant 3 affects only Intel and was the most hyped as it allows access to kernel space where the other two just leak data between processes at the same privilege level.
He means why the windows updates where blue screening on older AMD machines I think…
I have not seen an actual explanation other than something was documented incorrectly by AMD and while the updates were written to AMD’s instructions, the actual hardware (older FX Series I think) choked on it.
Edited 2018-01-09 20:25 UTC
Indeed, I was referring to the patch issues bricking some AMD machines.
It is a bit perverse that the patch bricks computer using processors that don’t have the most critical bug.
Already Breached?
Ah, sorry then. Didn’t get that from the post. As far as how MS can goof up critical updates, they (and other OSes) support a ridiculous number of processors, processors that can have hundreds of issues in the errata (and sometimes not in the errata!). It’s easy to miss some, especially when rushing to patch something this critical and big. They probably did minimal testing to get it out as fast as possible.
JLF65,
You make a good point, that all these hardware variation and errata may be passing the abilities of software vendors to keep up and manage them. It’s no longer enough just to write correct code, we also have to contend with erratic hardware. Even in linux there are instances of code where things were done in a weird way because of some weird hardware and the errata just keeps adding up to the point where nobody can understand the whole thing. It is like a house of cards, we can go in and “fix” a piece of code that seems wrong, but without a sufficient appreciation for why it was originally developed that way we may in fact be the ones to break it. The “it works for me” philosophy doesn’t work when there are just too many combinations to grasp. It makes correctness less absolute and more probabilistic, since the same code can be factually correct in the author’s context, and nevertheless be broken in another context or on different hardware.
I know it’s not going to happen because reasons, but I often wish we could re-architect our systems and come up with better standards, given what we know now in hindsight. It would simplify CPUs and operating systems greatly to get a fresh start without all the legacy baggage.
Edited 2018-01-09 22:04 UTC
Hardware houses so often present documentation reflecting a Conceptual Model of their products. Erratas forced to follow up. Guaranteed Mess…
That wouldn’t be possible at
http://www.osnews.com/story/30151/An_8-tube_module_from_a_1954_IBM_…
Edited 2018-01-09 22:40 UTC
The problem of separating form from function in electronics started with those “embedded” on black acrylics circuits.
“Reverse” engineering started then: tools were a hammer and a chisel.
But in principle was not right to buy those embedded circuits.
But in principle is not right to buy integrated circuits not publishing the printing screens of their silicon.
We are in a wrong path.
edit: where to were.
Edited 2018-01-10 15:33 UTC
You mean like with the T2 coprocessor?
They not “rushed” the patch, they’re working on it since last june, when the bug was found.
If they’ve had 6 months to test it, it shouldn’t be bricking computers…
It shouldn’t, but since their politic of cpu support is scarce, I cannot judge why they haven’t figured out this one earlier. Perhaps just as this bug target a very specific and sensitive part of a cpu it is triggered in a very specific hardware combination.
Reminder : https://www.ghacks.net/2017/03/17/microsoft-blocks-updates-for-new-c…
Since they consider a load of cpus as eol, they perhaps not conducted a thorough regression testing on them.
Update : http://www.zdnet.com/article/microsoft-says-older-windows-versions-…
“It’s understood that the company shut out Windows users with incompatible antivirus because of the risk to instability and blue-screen system crashes.”
Maybe just a bug introduced by an antivirus that prevented the patch from being applied completely.
Edited 2018-01-10 11:54 UTC
Kochise,
I read this too, but it may not have been a “bug” as some of these AV products may have genuinely been using the previous memory mapping model. Considering how extensive the changes were on linux, it would not surprise me that some 3rd party drivers are broken on windows.
Clean testing doesn’t equals on the wild testing.
Saying Satya to re-instantiate voluntary early testing.
Just commenting that BIOS is high priced vector. Maybe updates should start by re-injecting las known good code there.
Open BIOS works are quickly coming unavoidable. EFI/UEFI doesn’t fill this huge void. [Move your “rights” management code to a physical “black box”]. [Bill, this has business logic, you couldn’t possible manage all thousands mobo configs, requiring each a slightly modified code writing. Many of those manufacturers doesn’t maintain those blocks of code beyond 12 months].
Edited 2018-01-10 16:05 UTC
Given AMD’s track record for documentation and updates, this is easy to understand. They (AMD) probably aren’t even aware of all the combinations of hardware versions and microcode updates, and runtime drivers, and whatever else can effect compatibility. It’s AMD after all.
Microsoft’s statement implies that they didn’t even test it. They used specs, that may have been outdated. We don’t know. I see this as Microsoft screwing up another update. More of our customers ask if they should switch away from Windows. It’s hard not to advise against doing so, when Linux Mint works so well.
So, is KPTI (or whatever the microsoft equivalent is called) now enabled by default on Windows systems with AMD processors? There’s not a single mention of AMD in the blog post.
There’s tons of benchmarks for linux on phoronix. So far they show a fairly uniform performance hit across the cpus tested, ivy bridge up through whatever is newest in some of his testing.
On Linux you can disable the patch by using the nopti or pti=no boot parameter, is there a way to do the same with Windows?
Most normal users wouldn’t even need to protect against these flaws unless they were extremely paranoid, it’s just panic stations at the moment because of it all!
Most normal people wouldn’t even need to lock their doors unless they were extremely paranoid, it’s just panic stations because there’s a burglar on the loose!
Yeah whatever, idiot! Got the answer to the question or just gonna keep blowing hot air?
JavaScript in your browser can be xploited, so I wouldn’t advise to disable this option on a Desktop, be it Windows o Linux.
That said, some servers could benefit from the performance so it’d be god to know how to disable it.
No need to call anyone an idiot, BTW. It only reflects poorly on you.
Edited 2018-01-10 18:28 UTC
One could ask u the same question…
Your analogy doesn’t really pan out in this instance. At least in the USA, your home most likely has at most 2 locks on each external door: one on the knob and a dead bolt. The one on the knob is much less secure than the dead bolt, as it is relatively easy to use a plastic card to bypass, making the deadbolt the only real thing preventing most people from entering your house.
In computer security, we have layers upon layers of different security controls, but none of them are treated like the ineffectual “knob lock” I mentioned on a typical US home. Once a security control has been compromised to the point of having an easily-used bypass, it’s just not considered a security control anymore.
What I think the OP was saying was that these kinds of attacks assume that the attacker already had the ability to execute code on the victim’s system. Many systems which will be unquestioningly patched simply aren’t in a position to need the patch. For instance, if you have a large cluster of servers on the interior of a closed network with many security controls (“dead bolts” in the house analogy) governing access to said network, then you might reasonably be willing to forego these patches in order to retain the computational abilities of your cluster.
If, however, you run a system in which there are fewer controls governing access, and the likelihood of someone being able to gain user-level access to the system is higher, then these patches are much more valuable. As we’ve seen, they’ve already demonstrated attacks orchestrated via JavaScript, so desktop users are among those that should be deploying these patches regardless.
To answer the question, yes, it is possible to disable on Windows as well. Here’s a KB article on it. https://support.microsoft.com/en-us/help/4072698/windows-server-guid…
While the article only talks about Windows Server 2016 the registry entries are applicable to Windows 10 as well.
Internet filed with lists of affected with at least one variant.
AnySoul has a list of those non affected?
:/
Was about to buy a new laptop, but this keep me waiting…
Edited 2018-01-10 21:59 UTC
For Emergency Digital Banking:
Disable all cpu’s except the first. Always been AMD don’t know if Intel should disable hyper-treading too.
Boot live from Debian, preferably x86. [don’t forget to change default root password].
Download fresh bios, update from bios itself, or from free-dos if not.
Of Course, this doesn’t cover your bank security measures.
Edited 2018-01-10 22:39 UTC
A good worded article on the first after shocks of Meltdown and Spectre mitigation:
https://www.wired.com/story/meltdown-and-spectre-patches-take-toll/
The Fixing will take the original recomendation: Eventual MB replacement.