Look at the status before and after applying them. Any that stay mitigated are being handled via microcode

Sent via telekinesis

@Squid is right. It's a nicer two-fer. Since we are in a world of chips right now that are not immune to these attacks at the HW level, we are getting updates in two channels right now. BIOS level microcode updates, Windows patch level updates, linux kernel level patches and microcode updates. etc.... Okay so more than two channels 🙂 (It's a mess is the easy way).

 

With that, only some vulnerabilities are addressed at the BIOS level with microcode. Others are being handled by patches and updates. To FULLY disable it all, would require not only staying on an older un-patched BIOS (for some, they may have no option as MB vendors and Intel are only retrofitting but so far back), but also applying these mitigations. I don't really recommend staying on an old BIOS as other features come in newer BIOS versions, like AGESA updates and CPU compatibility for newer Chips on older chipsets. As noted in the plugin, there are still a good amount of mitigations we can disable at the kernel level, and users are seeing perf gains in the VM space.

 

As new CPU's are patched at the hardware level, this will be even more confusing since we will have microcode in BIOS updates that apply only to certain CPU's, but not other ones, and then patches at the OS level that will seemingly apply to everyone since we all pay the price at the OS level.

Edited June 14, 20197 yr by cybrnook

Disabling the patches gave me a 2.4% boost (5 tests averaged) on a Threadripper 2990WX using Passmark's CPU benchmark only testing against a single numa node in a Win 10 VM.

Edited June 14, 20197 yr by jbartlett

6 hours ago, jbartlett said:

Disabling the patches gave me a 2.4% boost (5 tests averaged) on a Threadripper 2990WX using Passmark's CPU benchmark only testing against a single numa node in a Win 10 VM.

Thanks for the input. So, in your case for one, you are an AMD system not Intel. So your platform isn't as heavily hit as say my 2011v3 based Intel systems, since Intel is really behind the ball on these patches.

 

As well, I don't want the impression that disabling these is a magic +%30 performance boost across the board on all benchmark suites, that's absolutely not the case. But what we can see, like from @zoggy 's EXCELLENT pre/post test case on an Intel based system, he see's perf boosts across the board, and up to %80 improvement in context switching (almost at the bottom of the page): https://openbenchmarking.org/result/1906037-HV-190603PTS41,1906033-HV-190603PTS92

 

So the benefits are real, if your use cases are in alignment, and are Intel based. Not to say though that disabling the overhead on an AMD system is not fruitful as well, especially on the OS level. Just don't expect an even +%30 across the board, all platforms, etc....

 

With that said, I look forward to maybe bouncing some ideas off you when I get my 2970WX system up and running. It's all here, just no time to actually build it out 🙂 Plus the fact we have been battling SLES scheduling issues on IBM Power at work, and  it's issues that we faced on incorrect affinity scheduling/assignments to non-optimal numa nodes.... I am taking a little time before hopping right back into that 🙂

Edited June 15, 20197 yr by cybrnook

36 minutes ago, cybrnook said:

So the benefits are real, if your use cases are in alignment, and are Intel based. Just don't expect an even +%30 across the board, all platforms, etc....

Honestly, getting 2 or 3% on average is already a lot in my book and enough to bother. People overclock and sometimes stress their components a lot for barely more than that. Getting more than that in some specific scenarios is just a nice bonus.

I'm not complaining about my 2-3%. I'm simply stating the results I got when I benchmarked the difference for an AMD system for others to be informed.

Has anyone updated to 6.7.1 or 6.7.2 and can confirm that this still works properly for the new zombieland vulnerability?

I assume everything is fine looking at cybrnook's post.

 

 

Edited June 25, 20197 yr by dnLL

17 minutes ago, dnLL said:

Has anyone updated to 6.7.1 or 6.7.2 and can confirm that this still works properly for the new zombieland vulnerability?

I assume everything is fine looking at cybrnook's post.

 

 

mds=off is for zombieload

Re: 80% improvement in context switching.

I run win10 vm's on my Intel 2670 dual cpu server and they seem more laggy recently. Am I one who will really notice the benefits of this plugin?

Sent from my chisel, carved into granite

2 hours ago, tr0910 said:

win10 vm's

Not the real expert, but it seems to me that Windows will have its own mitigations installed via updates which will override these on the VM.  You can also disable them via googling.

How much more power i can expect? Is it noticeable? (e.g. if you encode videos?) i have 6700k

27 minutes ago, nuhll said:

How much more power i can expect? Is it noticeable? (e.g. if you encode videos?) i have 6700k

0%-10%

So its maybe 10 min time safe, not really worth it, i guess.

On 6/2/2019 at 3:03 PM, Squid said:

My Settings Tab is getting too full   IE: I don't know.  Just where I initially thought it would go.  Initially I was going to stick it next to Syslinux Configuration under Flash Settings, but since I can never easily remember where exactly syslinux settings is in the first place, I figured that was a pointless place to put it.

I've often thought that the Tools tab is where most plugins should be. Most of mine are tools/utilities, not settings. 

I am running 6.8-RC4, installed the plugin, clicked disabled mitigations, rebooted, and still the plugin says mitigations are enabled.... Anything I am doing wrong?

 

Could there be issues with all the other stuff I have in the configuration?

 

Also, here is my Server's info, pretty old BIOS, shouldn't be patched for all vulnerabilities:

Edited October 31, 20196 yr by huntastikus
Added Mobo info

Without looking up your CPU etc are you still running 6.8 or did you downgrade to 6.7

2 minutes ago, Squid said:

Without looking up your CPU etc are you still running 6.8 or did you downgrade to 6.7

Just made the edit on the version, I am running 6.8 rc4, dual E5-2690 V2

Edited October 31, 20196 yr by huntastikus

https://www.techarp.com/guides/complete-meltdown-spectre-cpu-list/5/ My CPUs are on the list of vulnerable list

I am also running Unraid Nvidia (provided by the great peeps from linux server), do you think it would be a thing they may have included in the image?

It says that it's currently enabled.  And on a reboot, it's still saying enabled?  (And you are leaving the system to boot into GUI mode)  Could be a bug in the detection because you've got 2 append lines  (everything can go onto a single line), which may also mess up the boot and it's only doing the second line, not the first. (out of my control)

Edited October 31, 20196 yr by Squid

13 hours ago, huntastikus said:

I am also running Unraid Nvidia (provided by the great peeps from linux server), do you think it would be a thing they may have included in the image?

Actually, here's the easy way to tell if the two append lines are messing up the boot.  What's the output of

cat /proc/cmdline

 

the result is: BOOT_IMAGE=/bzimage pcie_acs_override=downstream vfio-pci.ids=8086:10e8,8086:105e,1b73:1100 isolcpus=6-9,26-29 initrd=/bzroot,/bzroot-gui

Yeah, the system is only picking up the second append line ( you're also missing kvm-intel.nested=1 ).  Combine both lines into a single one and get rid of the second.

11 hours ago, Squid said:

It says that it's currently enabled.  And on a reboot, it's still saying enabled?  (And you are leaving the system to boot into GUI mode)  Could be a bug in the detection because you've got 2 append lines  (everything can go onto a single line), which may also mess up the boot and it's only doing the second line, not the first. (out of my control)

Alas, you were correct, I combined both lines into 1, mitigations are off now, and all my parameters are working now. Thank you very much

I noticed with the latest kernel revert, plugin was still using mitigations=off, which won't work on the 4.* kernel, sigh...

Edited December 5, 20196 yr by cybrnook