Microsoft patches Visual C++ against Meltdown and Spectre and advises developers to patch their apps and games

[AlTech]

Yes, I know this news is a bit old but it's worth sharing nonetheless.

 

Despite OS Updates, BIOS updates, CPU firmware updates etc being released lately. The issue of Speculative execution in the form of Meltdown and Spectre on modern CPUs is still there.

 

Now it's time for Apps and Games to be patched against Meltdown and Spectre.

 

Microsoft has mitigated Spectre and Meltdown in their latest revisions of Visual C++ Toolchain in Visual Studio. They are patching the Visual C++ Toolchain in Visual Studio 2015 Update 3, Visual Studio 2017 RTW (Release to Web March 2017 version) and an upcoming update to Visual Studio 2017 version 15.5

 

Visual C++ Redistributables will be updated to patch against all forms of Spectre and Meltdown.

 

Quote

Microsoft is aware of a new publicly disclosed class of vulnerabilities, called “speculative execution side-channel attacks,” that affect many operating systems and modern processors, including processors from Intel, AMD, and ARM. On the MSVC team, we’ve reviewed information in detail and conducted extensive tests, which showed the performance impact of the new /Qspectre switch to be negligible. This post is intended as a follow-up to Terry Myerson’s recent Windows System post with a focus on the assessment for MSVC. If you haven’t had a chance to read Terry’s post you should take a moment to read it before reading this one.

 

Quote

The security researchers that discovered these vulnerabilities identified three variants that could enable speculative execution side-channel attacks. The following table from Terry’s blog provides the decoder ring for each of these variants:

 

 

Quote

What actions do developers need to take?

If you are a developer whose code operates on data that crosses a trust boundary then you should consider downloading an updated version of the MSVC compiler, recompiling your code with the /Qspectre switch enabled, and redeploying your code to your customers as soon as possible. Examples of code that operates on data that crosses a trust boundary include code that loads untrusted input that can affect execution such as remote procedure calls, parsing untrusted input for files, and other local inter-process communication (IPC) interfaces. Standard sandboxing techniques may not be sufficient: you should investigate your sandboxing carefully before deciding that your code does not cross a trust boundary.

In current versions of the MSVC compiler, the /Qspectre switch only works on optimized code. You should make sure to compile your code with any of the optimization switches (e.g., /O2 or /O1 but NOT /Od) to have the mitigation applied. Similarly, inspect any code that uses #pragma optimize([stg], off). Work is ongoing now to make the /Qspectre mitigation work on unoptimized code.

The MSVC team is evaluating the Microsoft Visual C++ Redistributables to make certain that any necessary mitigations are applied.

 

Microsoft have stated that the impact of performance is negligble for the Visual C++ Toolchain mitigations against Spectre. They claim that Windows itself has been compiled using it and there has been fairly minimal impact on Windows.

 

There will be lost performance on code bases which heavily relied on Speculative Execution. But that's just the way things have to be unfortunately.

 

Hopefully app and game developers using Visual C++ will update older apps and games as well as newer apps and games.

 

The source article has a lot more detail than this. If you're interested in specific types of mitigations etc if you're a developer then you may wish to take a look at the source.

 

So yeah, cool. Hopefully other programming languages are updated in a similar fashion if they need to be to mitigate meltdown and spectre.

 

If you're a developer using Visual C++ then i'd definitely advise you to re-compile your apps to patch against Meltdown and Spectre.

 

Source:

https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/?utm_source=vs_developer_news&utm_medium=referral

[LAwLz]

Like I said in my status update, this is a very weak and narrow mitigation. Basically, only a tiny modification of an exploit using Spectre could potentially bypass this. 

 

https://linustechtips.com/main/profile/216-lawlz/?status=189150&type=status

 

That's not Microsoft's fault though. They have chosen to optimize their automatic Spectre mitigation feature for performance rather than security, because there is a MASSIVE performance hit if they went full out for security. 

[yian88]

I think this whole meltdown spectre patches are pointless, i dont even understand why there have to be patches everywhere(should have documented myself better), at CPU microcode level at kernel level at binary generation level, at gpu/driver level, at app/game level WTF? just patching the kernel ruins performance and if you go up the entire abstraction layers with patches you get what ? games running at 10 fps with stutter?

I think everyone should rather be pushing for new CPU design asap and promote upgrading instead.

I have not heard of any major exploit wreaking havok due to these vulnerabilities, like wannacry, so what are we vulnerable to again?

[AlTech]

1 minute ago, yian88 said:

I think this whole meltdown spectre patches are pointless, i dont even understand why there have to be patches everywhere(should have documented myself better), at CPU microcode level at kernel level at binary generation level, at gpu/driver level, at app/game level WTF? just patching the kernel ruins performance and if you go up the entire abstraction layers with patches you get what ? games running at 10 fps with stutter?

Until now, the patches have caused negligible impact on Gaming Performance. This is mostly because the patches are not actually fully implemented proper secure implementations. They are designed to mitigate the issue to some extent without killing CPU performance.

 

For all intents and purposes, the patches are bandaid fixes and are not meant to be an end all be all solution. The ultimate solution is to get new hardware.

1 minute ago, yian88 said:

I think everyone should rather be pushing for new CPU design asap and promote upgrading instead.

The first AMD CPU to be patched on a Hardware level is coming in 2019 with Zen2.

 

It would be fair to assume the first Intel CPU with this patched at the hardware level is also coming in 2019.

1 minute ago, yian88 said:

I have not heard of any major exploit wreaking havok due to these vulnerabilities, like wannacry, so what are we vulnerable to again?

Malware, viruses, and malicious apps and programs.

 

49 minutes ago, LAwLz said:

That's not Microsoft's fault though. They have chosen to optimize their automatic Spectre mitigation feature for performance rather than security, because there is a MASSIVE performance hit if they went full out for security. 

Then why not offer the ability to go full out?

 

Then developers could choose to enable the highly secure option or the weak option.

[Trixanity]

4 minutes ago, yian88 said:

I think this whole meltdown spectre patches are pointless, i dont even understand why there have to be patches everywhere(should have documented myself better), at CPU microcode level at kernel level at binary generation level, at gpu/driver level, at app/game level WTF? just patching the kernel ruins performance and if you go up the entire abstraction layers with patches you get what ? games running at 10 fps with stutter?

I think everyone should rather be pushing for new CPU design asap and promote upgrading instead.

I have not heard of any major exploit wreaking havok due to these vulnerabilities, like wannacry, so what are we vulnerable to again?

CPU designs are years in the pipeline. You don't just roll out a new design over the weekend. There will be some mitigation later this year in Intel's designs I believe and everyone should have something in place by next year.

 

I don't think the performance reduction stacks like you think. I think the reason everything gets patched is to improve mitigation. Having multiple stages of protection helps. For example if your phone is vulnerable but doesn't get updated it's nice that new software protects you by working around the vulnerability.

 

Putting it in hardware prevents any downgrade or workaround exploit. I think most exploits published are at a hypothetical level in that they're patched before they're seriously exploited which is the best scenario.

[Doobeedoo]

So everyone wait and get Zen2 hue. 

 

But oh man this reminded me of Visual C++ Redistributables problems I've had for the past week. Those runtime packages libraries screwing with launching programs or even crashes. They can be such nuisance sometimes. 

I've had a problem upon program launch it get's stuck on initial loading with 100% cpu usage until I closed. Managed to fix but ugh. 

[Zodiark1593]

4 hours ago, yian88 said:

I think this whole meltdown spectre patches are pointless, i dont even understand why there have to be patches everywhere(should have documented myself better), at CPU microcode level at kernel level at binary generation level, at gpu/driver level, at app/game level WTF? just patching the kernel ruins performance and if you go up the entire abstraction layers with patches you get what ? games running at 10 fps with stutter?

I think everyone should rather be pushing for new CPU design asap and promote upgrading instead.

I have not heard of any major exploit wreaking havok due to these vulnerabilities, like wannacry, so what are we vulnerable to again?

So I'll be getting my free PC and mobo from you then???

[LAwLz]

On 2/18/2018 at 1:52 PM, AluminiumTech said:

Then why not offer the ability to go full out?

 

Then developers could choose to enable the highly secure option or the weak option.

Good question. I don't know why they don't allow it, but chances are nobody would use it.

 

The link I posted can be a bit difficult to read but the quick and dirty summary is this:

1) Speculative execution is VERY important for performance.

2) The fix for Spectre version 1 (affects all processors) it to deny any access to an array element which has not yet been confirmed to exist.

3) There is no specific instruction to block speculative execution today, because it was never a problem. It's simply not defined in any of the instruction sets. ARM is actually working on one called CSDB. As soon as the processor encounters the CSDB instruction, it will halt and not speculatively execute anything after that instruction.

 

4) x86 however, has some instructions such as CPUID and LFENCE which are "serializing instructions". Their purposes aren't to block speculative execution, but they have always had that as a side effect besides their intended purposes. For example CPUID is actually meant to be used for fetching data about the processor such as if it's 32bit or 64bit, what instructions it supports and so on. It just so happens that they also prevent processors from executing things speculatively beyond them.

 

5) It is already possible to manually go through your code and add a serializing instruction whenever you think the processor will speculatively access, but doing this is slow since you need to go through your code one line at a time, and look for instances where speculative execution might occur (which is not all array accesses mind you).

 

6) Microsoft's new VS compiler inserts LFENCE instructions in places where it detects that there will be speculative accesses.

 

But here is the thing... It is extremely hard to create a compiler which can accurately detect when speculative execution will or won't occur. Too few LFENCE instructions and it won't protect all of your code. Too many and performance goes down the drain. So Microsoft are trying to find a balance between safety and performance for their automatic tool. So do you risk that some of the data in your program can leak, or do you cut performance in half? The third alternative is of course doing it manually.

Their current VS compiler will only inserts LFENCE instructions in places where it is absolutely certain that the code is vulnerable. In instances where it is a bit less certain if it's a risk or not it opts to not insert LFENCE in order to preserve performance.

[vanished]

Maybe I just don't understand this but I have several questions...

1. why would apps need to be patched?  surely not for security?  I can see them potentially needing to be patched in order to not crash on patched systems since the OS patch may block things the programs previously did, but beyond that I don't see what they could possibly be doing here.
2. Why has everyone just accepted that there will be a performance hit associated with this patch?  Or well, I know why, because we're basically disabling speculative execution... but why are we doing that?  It's an essential tool for performance, we can't just give up.  Shouldn't the actual solution be to not allow unauthorized programs to pull random bits of data out of the CPU that they don't own rather than to just stop doing speculative execution?  Seems to me like banning ownership of items rather than just inventing locks as a solution to theft.

[AlTech]

3 minutes ago, Ryan_Vickers said:

Why has everyone just accepted that there will be a performance hit associated with this patch?  Or well, I know why, because we're basically disabling speculative execution... but why are we doing that? 

Because it turns out that it can be exploited.

[vanished]

Just now, AluminiumTech said:

Because it turns out that it can be exploited.

did you read the rest...?

[AlTech]

1 minute ago, Ryan_Vickers said:

did you read the rest...?

Yeah.

6 minutes ago, Ryan_Vickers said:

It's an essential tool for performance, we can't just give up.  Shouldn't the actual solution be to not allow unauthorized programs to pull random bits of data out of the CPU that they don't own rather than to just stop doing speculative execution?

That puts too much trust and responsibility onto the OS guys and frankly the issue is a CPU problem and not an OS problem.

 

It's like breaking your arm and then asking for a bandaid and not surgery.

6 minutes ago, Ryan_Vickers said:

Seems to me like banning ownership of items rather than just inventing locks as a solution to theft.

The Linux implementation of combating Meltdown is a lot worse than the Windows one from what I've seen.

 

The Linux Kernel treats all CPUs (unless the CPU series or brand name is whitelisted) as insecure and uses Shadow copies of Kernal Page Tables so that not every program has the real copy.

 

For Spectre, Linux uses Retpoline which has negligible impact on performance. Yes, you could argue it's wayy too weak against Spectre and malicious apps.

[vanished]

2 minutes ago, AluminiumTech said:

Yeah.

That puts too much trust and responsibility onto the OS guys and frankly the issue is a CPU problem and not an OS problem.

 

It's like breaking your arm and then asking for a bandaid and not surgery.

The Linux implementation of combating Meltdown is a lot worse than the Windows one from what I've seen.

 

The Linux Kernel treats all CPUs (unless the CPU series or brand name is whitelisted) as insecure and uses Shadow copies of Kernal Page Tables so that not every program has the real copy.

 

For Spectre, Linux uses Retpoline which has negligible impact on performance. Yes, you could argue it's wayy too weak against Spectre and malicious apps.

ok well I guess I need to look into how this works in more detail then.  Seems to me like it should be fixed in silicon and at the OS level, and that it should theoretically be possible to do it without much if any performance hit, but clearly that's not the common opinion.