Linked by Thom Holwerda on Tue 9th Jan 2018 18:03 UTC
Windows

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.

Order by: Score:
More data
by Alfman on Tue 9th Jan 2018 19:11 UTC
Alfman
Member since:
2011-01-28

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:

With Windows 10 on newer silicon (2016-era PCs with Skylake, Kabylake or newer CPU), benchmarks show single-digit slowdowns, but we don’t expect most users to notice a change because these percentages are reflected in milliseconds.

With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance.

With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), we expect most users to notice a decrease in system performance.


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.

Reply Score: 4

RE: More data
by Kochise on Tue 9th Jan 2018 23:35 UTC in reply to "More data"
Kochise Member since:
2006-03-03

Obviously it bricks AMD based computers. At least no more attack vector :

https://betanews.com/2018/01/08/microsoft-meltdown-spectre-patch-bri...

Reply Score: 1

RE: More data
by moondevil on Wed 10th Jan 2018 07:03 UTC in reply to "More data"
moondevil Member since:
2005-07-08

Indirection is a crucial component of many object oriented languages like C++, disabling it shouldn't effect windows and linux that much


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

Reply Score: 3

RE[2]: More data
by Alfman on Wed 10th Jan 2018 13:23 UTC in reply to "RE: More data"
Alfman Member since:
2011-01-28

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

Reply Score: 2

RE[3]: More data
by moondevil on Wed 10th Jan 2018 14:31 UTC in reply to "RE[2]: More data"
moondevil Member since:
2005-07-08

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

Reply Score: 4

RE: More data
by Lennie on Wed 10th Jan 2018 11:13 UTC in reply to "More data"
Lennie Member since:
2007-09-22

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

Reply Score: 2

RE[2]: More data
by BeamishBoy on Wed 10th Jan 2018 15:07 UTC in reply to "RE: More data"
BeamishBoy Member since:
2010-10-27

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?

Reply Score: 3

RE[3]: More data
by grat on Wed 10th Jan 2018 15:34 UTC in reply to "RE[2]: More data"
grat Member since:
2006-02-02

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.

Reply Score: 1

RE[4]: More data
by leech on Wed 10th Jan 2018 20:44 UTC in reply to "RE[3]: More data"
leech Member since:
2006-01-10

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

Reply Score: 0

RE[2]: More data
by Alfman on Wed 10th Jan 2018 16:11 UTC in reply to "RE: More data"
Alfman Member since:
2011-01-28

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?

Reply Score: 4

Interesting...
by osvil on Tue 9th Jan 2018 19:14 UTC
osvil
Member since:
2012-10-25

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

Reply Score: 4

RE: Interesting...
by JLF65 on Tue 9th Jan 2018 19:58 UTC in reply to "Interesting..."
JLF65 Member since:
2005-07-06

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.

Reply Score: 2

RE[2]: Interesting...
by galvanash on Tue 9th Jan 2018 20:22 UTC in reply to "RE: Interesting..."
galvanash Member since:
2006-01-25

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

Reply Score: 5

RE[3]: Interesting...
by osvil on Tue 9th Jan 2018 20:25 UTC in reply to "RE[2]: Interesting..."
osvil Member since:
2012-10-25

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.

Reply Score: 5

RE[4]: Interesting...
by dionicio on Tue 9th Jan 2018 20:31 UTC in reply to "RE[3]: Interesting..."
dionicio Member since:
2006-07-12

Already Breached?

Reply Score: 1

RE[4]: Interesting...
by JLF65 on Tue 9th Jan 2018 20:52 UTC in reply to "RE[3]: Interesting..."
JLF65 Member since:
2005-07-06

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.

Reply Score: 4

RE[5]: Interesting...
by Alfman on Tue 9th Jan 2018 21:56 UTC in reply to "RE[4]: Interesting..."
Alfman Member since:
2011-01-28

JLF65,

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.


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

Reply Score: 4

RE[6]: Interesting...
by dionicio on Tue 9th Jan 2018 22:23 UTC in reply to "RE[5]: Interesting..."
dionicio Member since:
2006-07-12

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

Reply Score: 1

RE[7]: Interesting...
by dionicio on Wed 10th Jan 2018 15:31 UTC in reply to "RE[6]: Interesting..."
dionicio Member since:
2006-07-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

Reply Score: 1

RE[6]: Interesting...
by kwan_e on Tue 9th Jan 2018 23:48 UTC in reply to "RE[5]: Interesting..."
kwan_e Member since:
2007-02-18

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.


You mean like with the T2 coprocessor?

Reply Score: 2

RE[5]: Interesting...
by Kochise on Tue 9th Jan 2018 23:38 UTC in reply to "RE[4]: Interesting..."
Kochise Member since:
2006-03-03

They not "rushed" the patch, they're working on it since last june, when the bug was found.

Reply Score: 1

RE[6]: Interesting...
by The123king on Wed 10th Jan 2018 09:41 UTC in reply to "RE[5]: Interesting..."
The123king Member since:
2009-05-28

If they've had 6 months to test it, it shouldn't be bricking computers...

Reply Score: 0

RE[7]: Interesting...
by Kochise on Wed 10th Jan 2018 11:50 UTC in reply to "RE[6]: Interesting..."
Kochise Member since:
2006-03-03

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

Reply Score: 0

RE[7]: Interesting...
by dionicio on Wed 10th Jan 2018 15:51 UTC in reply to "RE[6]: Interesting..."
dionicio Member since:
2006-07-12

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

Reply Score: 1

RE[4]: Interesting...
by CaptainN- on Thu 11th Jan 2018 17:40 UTC in reply to "RE[3]: Interesting..."
CaptainN- Member since:
2005-07-07

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.

Reply Score: 0

v RE[3]: Interesting...
by Seeprime on Tue 9th Jan 2018 20:39 UTC in reply to "RE[2]: Interesting..."
Comment by raom
by raom on Wed 10th Jan 2018 00:39 UTC
raom
Member since:
2016-06-26

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.

Reply Score: 2

linux benchies phoronix
by bnolsen on Wed 10th Jan 2018 00:44 UTC
bnolsen
Member since:
2006-01-06

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.

Reply Score: 3

Disable KPTI
by Sauron on Wed 10th Jan 2018 08:56 UTC
Sauron
Member since:
2005-08-02

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!

Reply Score: 2

RE: Disable KPTI
by The123king on Wed 10th Jan 2018 09:43 UTC in reply to "Disable KPTI"
The123king Member since:
2009-05-28

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!

Reply Score: 1

RE[2]: Disable KPTI
by Sauron on Wed 10th Jan 2018 13:57 UTC in reply to "RE: Disable KPTI"
Sauron Member since:
2005-08-02

Yeah whatever, idiot! Got the answer to the question or just gonna keep blowing hot air?

Reply Score: 2

RE[3]: Disable KPTI
by richarson on Wed 10th Jan 2018 18:27 UTC in reply to "RE[2]: Disable KPTI"
richarson Member since:
2014-05-24

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

Reply Score: 3

RE[3]: Disable KPTI
by xenolith on Wed 10th Jan 2018 18:40 UTC in reply to "RE[2]: Disable KPTI"
xenolith Member since:
2018-01-10

One could ask u the same question...

Reply Score: 1

RE[2]: Disable KPTI
by jasutton on Wed 10th Jan 2018 18:55 UTC in reply to "RE: Disable KPTI"
jasutton Member since:
2006-03-28

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.

Reply Score: 3

RE: Disable KPTI
by Undomiel on Wed 10th Jan 2018 22:02 UTC in reply to "Disable KPTI"
Undomiel Member since:
2007-11-23

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.

Reply Score: 3

Are those Lists exhaustive?
by dionicio on Wed 10th Jan 2018 21:58 UTC
dionicio
Member since:
2006-07-12

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

Reply Score: 1

Quick and Dirty...
by dionicio on Wed 10th Jan 2018 22:31 UTC
dionicio
Member since:
2006-07-12

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

Reply Score: 1

dionicio
Member since:
2006-07-12

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.

Reply Score: 2