www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
Performance impact of Spectre, Meltdown patches on Windows
By Thom Holwerda on 2018-01-09 18:03:36

From Microsoft's blog:

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.

 Email a friend - Printer friendly - Related stories
.
Post a new comment
Read Comments: 1-10 -- 11-20 -- 21-30 -- 31-39
.
RE[7]: Interesting...
By Kochise on 2018-01-10 11:50:48
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...

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/mic...

"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
Permalink - Score: 0
.
RE[2]: More data
By Alfman on 2018-01-10 13:23:09
moondevil,

> 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++


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
Permalink - Score: 2
.
RE[2]: Disable KPTI
By Sauron on 2018-01-10 13:57:46
Yeah whatever, idiot! Got the answer to the question or just gonna keep blowing hot air?
Permalink - Score: 2
.
RE[8]: Interesting...
By Alfman on 2018-01-10 14:24:11
Kochise,

> 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......

Since they consider a load of cpus as eol, they perhaps not conducted a thorough regression testing on them.


Yea that was a load of crap from microsoft to create artificial incentives to move to windows 10. Intel, for it's part, has always gone through great lengths to make their CPUs backwards compatible, and this was no exception. Yet despite intel's commitment to backwards compatibility, microsoft sought to make sure new CPUs would be unsupported as a matter of policy.

It would be disappointing to learn that intel has patches for spectre only to have microsoft block owners from receiving those updates for political/business reasons. Even so it doesn't completely explain why microsoft's OS updates are breaking some AMD computers, especially on older supported CPUs. I know the devil's got to be in the details...but it seems microsoft's OS updates were buggy and MS failed to test them adequately.

Like other posters, I'm also curious if microsoft's meltdown patch is being applied on AMD CPUs, where the attack is not known to work and the software workaround dramatically hurts syscall performance? It makes me contemplate which is better: supporting two different kernel execution models depending on the underlying CPU vulnerabilities, or just moving to one unified kernel model that punishes CPUs that are not vulnerable.


> "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.


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.
Permalink - Score: 1
.
RE[3]: More data
By moondevil on 2018-01-10 14:31:16
Here is an updated description from a Windows kernel team member at Reddit.

https://www.reddit.com/r/cpp/comm...
Permalink - Score: 4
.
RE[2]: More data
By BeamishBoy on 2018-01-10 15:07:33
> Why did I get the idea Microsoft is making Windows 7 and 8 slower on purpose to make sure people move to Windows 10.

Is it because you're a paranoid douchebag?
Permalink - Score: 3
.
RE[7]: Interesting...
By dionicio on 2018-01-10 15:31:12
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
Permalink - Score: 1
.
RE[3]: More data
By grat on 2018-01-10 15:34:42
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.
Permalink - Score: 1
.
RE[7]: Interesting...
By dionicio on 2018-01-10 15:51:25
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
Permalink - Score: 1
.
RE[2]: More data
By Alfman on 2018-01-10 16:11:23
Lennie,

> 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 ?



See this excerpt:
> Older versions of Windows have a larger performance impact because Windows 7 and Windows 8 have more user-kernel transitions because of legacy design decisions, such as all font rendering taking place in the kernel. We will publish data on benchmark performance in the weeks ahead.

This reasoning seems plausible, the kernel changes impose a large overhead for every syscall transition, including font rendering. So font subsystem benchmarks will likely show worse performance. However it's hard to imagine the font rendering really being a big enough bottleneck to begin with such that users could even notice, like the difference between 200FPS and 300FPS.


> Part 2 is: are they enabling that for all CPUs or all x86/AMD64 CPUs or only Intel CPUs ?

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?
Permalink - Score: 4

Read Comments 1-10 -- 11-20 -- 21-30 -- 31-39

Post a new comment
Username

Password

Title

Your comment

If you do not have an account, please use a desktop browser to create one.
LEAVE SPACES around URLs to autoparse. No more than 8,000 characters are allowed. The only HTML/UBB tags allowed are bold & italics.
Submission of a comment on OSNews implies that you have acknowledged and fully agreed with THESE TERMS.
.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?