Is it safe to turn off Metldown and Spectre security?

[Bombastinator]

Just now, BuckGup said:

So they swapped to raspberry Pis and dropped all tools they used written for x86. Yeah no

At least one swapped to such.  He prefers beaglebone.  Uses pi though.  That one also uses A Mac tablet.  Haven’t talked to the others in a long time.  Pi is by no means the only non x86 thing out there.  I vaguely recall a mention of a 24core arm machine.  Might have been risc5 or something which would work too.  They were all programmers that were security focused.  Part of the reason I didn’t my Linux and BSD chops are at best rudimentary.  I’m pretty much the computer retard of that crowd. I made the mistake in college of bringing a PC with me.  Everyone else had to use the school mainframes so they typed their papers in Kermit and learned Unix and wound up with six figure IT jobs while I snake toilets.  It was the heyday of the beginning of the internet.  One of them was just given an entire c block because ipv4 was new and they were just handing em out.  God knows what that is worth now.

[Kisai]

8 hours ago, AbdulRehmaann said:

Hi all, i was facing stutter in cities/populated areas in Red dead redemption 2 despite of stable FPS (65-75). I tried every fix i found online but none of them worked. Lastly, I was told to turn off Meltdown and Spectre security to see if it helps. I did and it fixed my problem but it leaves the Computer vulnerable. Someone mentioned that it is completely safe since this got patched but I will want to be sure if it is safe or not. Something i have come up with is to turn it off while playing RDR2 and turn it back on after i'm done playing but it seems like a hassle doing it every time i want to play that game. Note: RDR2 is the only game that is problematic. I'll list my specs below:

 

i7-4790 cooled by Cooler Master MA410p

16GB DDR3 1600mhz (4x4)

MSI Gaming X GTX 1070 8GB

240GB Gigabyte SSD (boot)

2TB WD HDD (Games)

If it was patched as a BIOS update, yeah, you could probably turn it off, but the thing is almost no haswell systems were. If it was patched in the BIOS, then the OS protections aren't used.

 

But the mitigation is worse than the BIOS update, as you lose like 5-20% of the performance of the CPU if it's done by the OS.

 

It's actually easier to just point at the CPU and go "that's not powerful enough for RDR2"

 

Those on Sandy Bridge and Ivy Bridge didn't get BIOS updates what-so-ever unless they were on specific Dell/HP Workstation models.

 

This is my Haswell system on a ASRock board with the Beta bios that patches meltdown:

For more information about the output below, please refer to https://support.microsoft.com/en-in/help/4074629

Speculation control settings for CVE-2017-5715 [branch target injection]

Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: True

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: True [not required for security]

Speculation control settings for CVE-2018-3639 [speculative store bypass]

Hardware is vulnerable to speculative store bypass: True
Hardware support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is enabled system-wide: False

Speculation control settings for CVE-2018-3620 [L1 terminal fault]

Hardware is vulnerable to L1 terminal fault: True
Windows OS support for L1 terminal fault mitigation is present: True
Windows OS support for L1 terminal fault mitigation is enabled: True


BTIHardwarePresent                  : True
BTIWindowsSupportPresent            : True
BTIWindowsSupportEnabled            : True
BTIDisabledBySystemPolicy           : False
BTIDisabledByNoHardwareSupport      : False
BTIKernelRetpolineEnabled           : True
BTIKernelImportOptimizationEnabled  : True
KVAShadowRequired                   : True
KVAShadowWindowsSupportPresent      : True
KVAShadowWindowsSupportEnabled      : True
KVAShadowPcidEnabled                : True
SSBDWindowsSupportPresent           : True
SSBDHardwareVulnerable              : True
SSBDHardwarePresent                 : True
SSBDWindowsSupportEnabledSystemWide : False
L1TFHardwareVulnerable              : True
L1TFWindowsSupportPresent           : True
L1TFWindowsSupportEnabled           : True
L1TFInvalidPteBit                   : 45
L1DFlushSupported                   : True

As for "should you in general"

 

If a system is vulnerable, it's vulnerable, but games are generally not going to be a target unless the game is a HTML5 game that actually connects to the internet. If you're really concerned, turn it off, and then disconnect the ethernet cable.

 

[Bombastinator]

Deleted due to pointless meandering caught too late.

[LAwLz]

The amount of misinformation in this thread is staggering.

 

 

 

14 hours ago, Bombastinator said:

It got mitigated.  It’s unpatchable.  I know people (all IT pros) who were bugged so much by specter/meltdown they flat out quit using x86 entirely and went arm.  I would have done it too but I like video games too much. (I’m a weak weak man) I won’t be turning it off ever myself.

If it's true that you know people who went to ARM over this then those people are very, very uninformed since both Meltdown and Spectre also affect ARM processors.

Meltdown and Spectre are not ISA dependent.

 

14 hours ago, 5x5 said:

Considering how extremely easy they are to execute, I'd say it's a very large risk. All it takes is one infected web page and you're fucked. There's a very good reason why the patches got rushed and all other development was paused

This is completely false.

1) They are not easy to execute. They are in fact very difficult to execute.

2) Even when they are executed, you might just get a bunch of gibberish data. The likelihood of the exploit working, and the exploit fetching some important data are is small.

3) You need more than an infected web page because all modern browsers now have mitigations in place.

 

 

13 hours ago, 5x5 said:

It's extremely easy to defraud someone using the exploits.

No it isn't.

13 hours ago, 5x5 said:

All you need is a legit looking site with an infected script.

No it's not.

 

 

12 hours ago, Curious Pineapple said:

Mine got no fix, Intel have a list of CPU's they did and didn't provide mitigations for.

It's important to note that there is not just one patch for meltdown and Spectre.

The patches hardware vendors have released are not the same as the wide variety of software vendors has released.

 

 

12 hours ago, Bombastinator said:

Skylake is hardware mitigated so it doesn’t take the performance hit the older stuff does.   Mitigation’s were put out though.  At least I’m pretty sure they were.   I’ve got an old intel machine and my understanding was that the software mitigation ate a significant chunk of processor speed on them.  It wasn’t as bad as the 100% fix of simply turning off preemptive multitasking though.   Do that and one of them vanishes.  I forget which one.  Hits your processor really really hard though a lot of ipc is premptive multitasking. 
 

NOTE: As noted below this may be BS.  I did think they started doing hardware mitigation with skylake, partially because they all the intel stuff  is called “skylake plus” of some sort these days.  It may have not started till AFTER skylake, which is kind of a big deal and makes the “skylake plus”claimers kind of wrong.

It depends on what vulnerability you are looking at. What's important to remember is that Spectre and Meltdown are not just two vulnerabilities. Those two are categories, which multiple vulnerabilities in each. Meltdown for example can be used to describe at least 3 vulnerabilities, and Spectre can be used to describe like 6 different vulnerabilities.

Different hardware has fixes for different vulnerabilities. For example Whiskey Lake has hardware fixes for Spectre variant 3, 3a and 5.

 

Also, I think people in general overstate the performance impact these patches have. We saw big numbers like 20% being thrown around but it's important to note that those numbers were from early patches that have since been replaced by far better performing patches such as retpoline, and those 20% numbers were deliberately cherry picked to make flashy headlines. The average impact of those patches were nowhere near 20%. It was maybe like 1 out of 20 workloads that were affected that dramatically.

 

 

13 hours ago, Bombastinator said:

Skylake is hardware mitigated so it doesn’t take the performance hit the older stuff does.

Skylake does not have hardware mitigation. Coffee Lake Refresh does, for some of the vulnerabilities (rogue data cache load and L1 terminal fault).

[LAwLz]

9 hours ago, 5x5 said:

AMD was mostly unscathed - their performance didn't take any hit since meltdown didn't affect them and spectre only barely affected some AM4 products so them itigation needed was minimal.

The part about "barely affected some AM4 products" is false. All AMD products at the time of publication were vulnerable to two out of the 3 disclosed vulnerabilities.

It was only really Meltdown-BK that AMD were safe from. Meltdown-BD was an issue for AMD too, as was Spectre v1 and Spectre v2.

The reason why AMD got away without a PR nightmare was because they kept silent as people were throwing shit on Intel. AMD being the underdog and the Internet generally hating Intel probably contributed quite a bit as well.

In reality, AMD were just barely less affected by Spectre and Meltdown than Intel. It's just that they didn't get as much bad press since they are smaller. AMD also made some statements early where they went something along the lines of "we believe that there is a near zero risk that people with AMD products will be affected" and people believed that meant "AMD products aren't affected". Then they didn't bother to look at the updated statement where AMD clarified that yes, their products were affected. They just didn't think the vulnerabilities were likely to be used on any of their customers, basically.

[Bombastinator]

6 hours ago, LAwLz said:

The amount of misinformation in this thread is staggering.

 

 

 

If it's true that you know people who went to ARM over this then those people are very, very uninformed since both Meltdown and Spectre also affect ARM processors.

Meltdown and Spectre are not ISA dependent.

 

This is completely false.

1) They are not easy to execute. They are in fact very difficult to execute.

2) Even when they are executed, you might just get a bunch of gibberish data. The likelihood of the exploit working, and the exploit fetching some important data are is small.

3) You need more than an infected web page because all modern browsers now have mitigations in place.

 

 

No it isn't.

No it's not.

 

 

It's important to note that there is not just one patch for meltdown and Spectre.

The patches hardware vendors have released are not the same as the wide variety of software vendors has released.

 

 

It depends on what vulnerability you are looking at. What's important to remember is that Spectre and Meltdown are not just two vulnerabilities. Those two are categories, which multiple vulnerabilities in each. Meltdown for example can be used to describe at least 3 vulnerabilities, and Spectre can be used to describe like 6 different vulnerabilities.

Different hardware has fixes for different vulnerabilities. For example Whiskey Lake has hardware fixes for Spectre variant 3, 3a and 5.

 

Also, I think people in general overstate the performance impact these patches have. We saw big numbers like 20% being thrown around but it's important to note that those numbers were from early patches that have since been replaced by far better performing patches such as retpoline, and those 20% numbers were deliberately cherry picked to make flashy headlines. The average impact of those patches were nowhere near 20%. It was maybe like 1 out of 20 workloads that were affected that dramatically.

 

 

Skylake does not have hardware mitigation. Coffee Lake Refresh does, for some of the vulnerabilities (rogue data cache load and L1 terminal fault).

Re: arm is susceptible

This arm is susceptible thing is fascinating to me.  It’s quite different than I was told.  I view the tellers as sort of the opposite of uninformed, though I definitely view myself as being such.  It could well have been oversimplified for my benefit when it was explained to me.

 

 The only difference between risc and non risc is microcode.  Arm could be implemented in a way that is.  I was given to understand it merely didn’t happen to be.  More a luck thing than a fundamental design thing.  if it was using predictive multitasking for example which could be done it would happen.  So not so much could it but was it.  Do you have any examples of non x86 systems with this issue?  Not a demand just a curiosity.

 

re: skylake

yeah I got it wrong on that one it seems.  My error was based on both timeline and constant references I see to  things being referred to as everything after haswell being referred to as haswell refreshes which implied to me that anything haswell was dealt with.  It’s apparently incorrect.  It’s in the thread.  Didn’t know whiskeylake was only partial. I did know some were partial.  I do have a Yorkdale cpu that has been unpowered in my basement since before the problem occurred.  My understanding is everything after cloverdale has problems, and Yorkdale is after cloverdale.

[LAwLz]

2 minutes ago, Bombastinator said:

Re: arm is susceptible

This arm is susceptible thing is fascinating to me.  It’s quite different than I was told.  I view the tellers as sort of the opposite of uninformed, though I definitely view myself as being such.  It could well have been oversimplified for my benefit when it was explained to me.

 

 The only difference between risc and non risc is microcode.  Arm could be implemented in a way that is.  I was given to understand it merely didn’t happen to be.  More a luck thing than a fundamental design thing.  if it was using predictive multitasking for example which could be done it would happen.  So not so much could it but was it.  Do you have any examples of non x86 systems with this issue?  Not a demand just a curiosity.

Yeah, there has been a ton of misinformation surrounding Spectre and Meltdown. People up playing it to make company X or Y look bad, or to get lots of clicks from juicy headlines. People downplaying it to save face, to not have their favorite brand be shat on, or to get lots of clicks from juicy headlines "processor X is not vulnerable, click here to find out why!".

 

Here is ARM's list of vulnerable processor architectures, which variant of Spectre/meltdown that they are vulnerable to, and if there is mitigation in place (such as a software or firmware patch that has been released).

https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability

Spoiler

 

[Bombastinator]

6 hours ago, LAwLz said:

The part about "barely affected some AM4 products" is false. All AMD products at the time of publication were vulnerable to two out of the 3 disclosed vulnerabilities.

It was only really Meltdown-BK that AMD were safe from. Meltdown-BD was an issue for AMD too, as was Spectre v1 and Spectre v2.

The reason why AMD got away without a PR nightmare was because they kept silent as people were throwing shit on Intel. AMD being the underdog and the Internet generally hating Intel probably contributed quite a bit as well.

In reality, AMD were just barely less affected by Spectre and Meltdown than Intel. It's just that they didn't get as much bad press since they are smaller. AMD also made some statements early where they went something along the lines of "we believe that there is a near zero risk that people with AMD products will be affected" and people believed that meant "AMD products aren't affected". Then they didn't bother to look at the updated statement where AMD clarified that yes, their products were affected. They just didn't think the vulnerabilities were likely to be used on any of their customers, basically.

This implies that AMD might not have done the same level of mitigation that intel did.  The AMD stuff people care about thes days most is ryzen.  Does ryzen have hardware mitigation?  

[Bombastinator]

9 minutes ago, LAwLz said:

Yeah, there has been a ton of misinformation surrounding Spectre and Meltdown. People up playing it to make company X or Y look bad, or to get lots of clicks from juicy headlines. People downplaying it to save face, to not have their favorite brand be shat on, or to get lots of clicks from juicy headlines "processor X is not vulnerable, click here to find out why!".

 

Here is ARM's list of vulnerable processor architectures, which variant of Spectre/meltdown that they are vulnerable to, and if there is mitigation in place (such as a software or firmware patch that has been released).

https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability

  Hide contents

 

Thanks.  Looking at the list it seems to jump around a bit.  For instance a10 and a11 aren’t mentioned though a12 is.  Does this mean a10 and a11 are not susceptible at all? Variant 1 seems to have problems all the way down.

[porina]

I have to admit, I tried the same. I had a game that was micro-stuttering and was looking for any cause that contributed to it. In my case, disabling this did not help at all.

 

Anyway, if we define mitigation as a means to prevent the problem from being exploited, then there are several ways this can be achieved.

 

Microcode update delivered in bios.

Microcode update delivered by OS.

OS code changes

Software code changes

Hardware design changes

 

Microcode mitigation was certainly available for Skylake, and I think Haswell too. They had more performance impacts the older you go. The more recent CPUs should have less impact, but I've not kept up with people who actually try to benchmark this kinda stuff, and they usually focus on software I never heard of or care about (servery stuff).

 

Windows certainly lets you disable the OS provided mitigation if you want to. I'm unclear if the bios/etc updates require software to make use of it to be effective. 

[LAwLz]

2 minutes ago, Bombastinator said:

This implies that AMD might not have done the same level of mitigation that intel did.  The AMD stuff people care about thes days most is ryzen.  Does ryzen have hardware mitigation?  

AMD has been pretty low-key with details about the entire thing. They have made a few blog posts about it but used a lot of words like "believe", "unlikely" and similarly vague terms to protect themselves legally, while also downplaying the issue quite a bit. Their first statement was that variant 2 had not been demonstrated on AMD processors and therefore there was a "near zero risk of exploitation"... Then like a week later they had to remove that statement and make a public statement that their processors were vulnerable.

So after that they were deliberately very careful with how much and what they said.

 

I am not entirely sure which variants of Spectre Ryzen processors were vulnerable to (there are like 9 different Spectre exploits now), but Zen 2 (Ryzen 3000 processors) implemented hardware mitigation for Spectre 1, 2 and 4. They were never vulnerable to variant 3 (Meltdown). Not sure about the other Spectre vulnerabilities.
 

 

 

14 minutes ago, Bombastinator said:

For instance a10 and a11 aren’t mentioned though a12 is.  Does this mean a10 and a11 are not susceptible at all?

Well, ARM's naming scheme is a bit confusing. There is no A10 or A11.

But you are correct when you say that if an architecture isn't on the list, then it's not vulnerable. For example Cortex-A55 is not on the list, because it isn't vulnerable (since it can't do speculative execution at all).

 

 

24 minutes ago, Bombastinator said:

Variant 1 seems to have problems all the way down.

Yep, variant 1 is the one that affects most processors. It's also called "Bounds Check Bypass" or BCB if you want to look into it.

When people say "you just need to browse a malicious website and you're fucked!" it's usually Spectre version 1 they are talking about. However, we have lots of mitigations for this already in place. If you just recompile your program with a newer version of Visual Studio you will get partial protection from Spectre v1 in your program (although it is not 100% efficient). Browsers have also added their own protection.

So if you've just updated your browser in the last ~2 years then you will have pretty solid protection against Spectre v1, even if you don't have any other protection (like OS update, firmware update, hardware mitigation in processor, etc).

[Kisai]

On 6/10/2020 at 8:35 AM, LAwLz said:

 

When people say "you just need to browse a malicious website and you're fucked!" it's usually Spectre version 1 they are talking about. However, we have lots of mitigations for this already in place. If you just recompile your program with a newer version of Visual Studio you will get partial protection from Spectre v1 in your program (although it is not 100% efficient). Browsers have also added their own protection.

So if you've just updated your browser in the last ~2 years then you will have pretty solid protection against Spectre v1, even if you don't have any other protection (like OS update, firmware update, hardware mitigation in processor, etc).

But that's not what developers do. They use the tools they have installed to avoid breaking their development pipeline. In Visual Studio there is an explicit "/QSpectre" flag that needs to be added, and only exists in VS2017 or later if it's been updated. Many software packages out there are not built with VS2017 because the developer made an active decision to make their software work on Windows XP (such as most emulators and pre-compiled cross-platform software libraries.) You can't mix Spectre and non-Spectre safe libraries, the linker will have a fit. Microsoft also patched VS2015 but it does not have the QSpectre flag.

 

LLVM has more info https://llvm.org/docs/SpeculativeLoadHardening.html on what the performance penalties are for optimization if mitigations are done.

 

Make tools like cmake ,don't automatically add such flags to Clang, Gcc or VS2017+ because it may break the software, and as stated in this thread, not all software even needs it. If it doesn't contain network logic, and isn't a VM, script Interpreter, or Emulator, then there's really no reason to take the performance loss at the application level, since there's no way to get malicious code into the program. Software like PDF readers, and MS Word/Excel would need it because such malicious code can exist in the embedded javascript or visual basic scripts. Your average game that is NOT a MMO, and has no IAP/DLC, does not need it, because it doesn't connect to the internet. If a game uses IAP then it essentially has an embedded web browser to deal with the purchase. Games that have embedded browsers as opposed to the OS webview are extremely vulnerable, but there's also much easier ways to attack a game with web-launchers/IAP systems, and even if you could use spectre to pull the game credentials out... a lot of these launchers just pass the login token on the command line, you don't need to go that far.

 

[LAwLz]

13 hours ago, Kisai said:

But that's not what developers do.

Yes, that is what a lot of developers do. Like I said earlier, all modern browsers have implemented several mitigations for Spectre for example. Microsoft have also done it in their products that have been updated since.

 

13 hours ago, Kisai said:

They use the tools they have installed to avoid breaking their development pipeline. In Visual Studio there is an explicit "/QSpectre" flag that needs to be added, and only exists in VS2017 or later if it's been updated. Many software packages out there are not built with VS2017 because the developer made an active decision to make their software work on Windows XP (such as most emulators and pre-compiled cross-platform software libraries.) You can't mix Spectre and non-Spectre safe libraries, the linker will have a fit. Microsoft also patched VS2015 but it does not have the QSpectre flag.

Where did you get the idea from that you can't mix Spectre and non-spectre safe libraries? You absolutely can. It is being done by lots of software, and the LLVM fix you linked does not mention it as a drawback.

 

 

13 hours ago, Kisai said:

Make tools like cmake ,don't automatically add such flags to Clang, Gcc or VS2017+ because it may break the software, and as stated in this thread, not all software even needs it. If it doesn't contain network logic, and isn't a VM, script Interpreter, or Emulator, then there's really no reason to take the performance loss at the application level, since there's no way to get malicious code into the program.

Totally agree. A lot of software certainly doesn't need it. I think your list of programs is a bit short though. Even if the program doesn't contain network functions, is a VM, script interpretor or emulator it can still be at risk. Anything that can interface with other programs could be a risk, but it depends on what info those programs contain. For example let's say you have a program that is completely local, doesn't contain any scripting APIs or the like, and contain a lot of sensitive info. If that program contains some exploit that allows arbitrary code execution, a virus running on the same computer could potentially chain exploits in a way where it can gain access.

It doesn't really matter that the program itself doesn't have network access, or a scripting engine, a virus could take advantage of Spectre anyway to gain info.

That scenario is very unlikely though, but I think the situation is a bit more complicated than "if you program doesn't do X or Y when it doesn't need updating".

 

It wasn't too long ago an exploit in Skia was discovered, where simply loading in a specially crafted image file could let an attack execute any code they wanted.

 

 

13 hours ago, Kisai said:

Your average game that is NOT a MMO, and has no IAP/DLC, does not need it, because it doesn't connect to the internet.

I would say those programs are safe from Spectre not because "they don't connect to the Internet" but rather because they don't contain any valuable information. Like I said earlier, a virus could still potentially use a Spectre vulnerability to extract info from a game that has no Internet functionality. But what's the point in doing all that work if you can't steal anything valuable?

[Bombastinator]

8 minutes ago, LAwLz said:

Yes, that is what a lot of developers do. Like I said earlier, all modern browsers have implemented several mitigations for Spectre for example. Microsoft have also done it in their products that have been updated since.

 

Where did you get the idea from that you can't mix Spectre and non-spectre safe libraries? You absolutely can. It is being done by lots of software, and the LLVM fix you linked does not mention it as a drawback.

 

 

Totally agree. A lot of software certainly doesn't need it. I think your list of programs is a bit short though. Even if the program doesn't contain network functions, is a VM, script interpretor or emulator it can still be at risk. Anything that can interface with other programs could be a risk, but it depends on what info those programs contain. For example let's say you have a program that is completely local, doesn't contain any scripting APIs or the like, and contain a lot of sensitive info. If that program contains some exploit that allows arbitrary code execution, a virus running on the same computer could potentially chain exploits in a way where it can gain access.

It doesn't really matter that the program itself doesn't have network access, or a scripting engine, a virus could take advantage of Spectre anyway to gain info.

That scenario is very unlikely though, but I think the situation is a bit more complicated than "if you program doesn't do X or Y when it doesn't need updating".

 

It wasn't too long ago an exploit in Skia was discovered, where simply loading in a specially crafted image file could let an attack execute any code they wanted.

 

 

I would say those programs are safe from Spectre not because "they don't connect to the Internet" but rather because they don't contain any valuable information. Like I said earlier, a virus could still potentially use a Spectre vulnerability to extract info from a game that has no Internet functionality. But what's the point in doing all that work if you can't steal anything valuable?