VMware Cloud Community
guan8
Contributor
Contributor

Concurrent-context attack vector vulnerability in Intel processors

Hello!

We are running a cluster of ProLiant DL380 Gen10 servers running VMware ESXi, 6.7.0, 10302608.

On each host, we are seeing a warning when browsing to Monitor => Health. The warning is "Concurrent-context attack vector vulnerability in Intel processors". After reading more about it here https://kb.vmware.com/s/article/55806​ , there is a paragraph that says:

Note: It may be necessary to acquire additional hardware, or rebalance existing workloads, before enablement of the ESXi Side-Channel-Aware Scheduler. Organizations can choose not to enable the ESXi Side-Channel-Aware Scheduler after performing a risk assessment and accepting the risk posed by the Concurrent-context attack vector. This is NOT RECOMMENDED and VMware cannot make this decision on behalf of an organization.

We have discussed this in our organization, and we wish to accept the risk and not enable this feature. How do we disable the warning from the vCenter web UI? Since we do not consider this warning relevant for us, we would like to reset this warning to green. Right now it is potentially obscuring other, more relevant warnings.

Thank you in advance.

/Gustav

pastedImage_2.png

22 Replies
guan8
Contributor
Contributor

Anyone have any information on this?

/Gustav Andersson

Reply
0 Kudos
Techie01
Hot Shot
Hot Shot

I am not entirely sure if this helps, but have tried the option provided in KB 56534 ( option about SuppressHyperthreadWarning)

Reply
0 Kudos
guan8
Contributor
Contributor

Hi,

Thank you for your answer. However, after checking, I can see that UserVars.SuppressHyperthreadWarning is already set to 1 per default on all our hosts. No warnings show up on the host on the summary tab and there are no issues or triggered alarms, but if I go to Host => Monitor => Health, I can see there are warnings displayed from the last health check.

/Gustav

pastedImage_1.png

pastedImage_2.png

pbraren
Hot Shot
Hot Shot

Same warning behavior noticed in my 3 node ESXi 6.7 Update 2 cluster in my home lab. All 3 defaulted to SuppressHyperthreadWarning value of 1, but warning still there.

Keeping an eye on this thread...

TinkerTry.com
Reply
0 Kudos
jacosta
Enthusiast
Enthusiast

I was able to clear the alert by modifying the two Kernel Values below, which was the inverse of how they were. 

VMkernel.Boot.hyperthreadingMitigation  =  True

VMkernel.Boot.hyperthreadingMitigationIntraVM = False

This applies to ESX 6.7 U2 , build 13006603; according to 3b in the linked article, lower versions are not supported for SCAv2.

Based on the below image (from KB Article 55806), this is a balance of performance and security.

Specific Info here:  VMware Knowledge Base

JoeA

User-added image

guan8
Contributor
Contributor

Hello jacosta,

Ok, so setting VMkernel.Boot.hyperthreadingMitigation or VMkernel.Boot.hyperthreadingMitigationIntraVM to True would hide the warning. Thank you for the clear explanation.

The original question was if there was a way to hide the warning if you do not wish to enable these mitigations because the vulnerability does not pose a threat to your business. This question is still unanswered.

Reply
0 Kudos
jacosta
Enthusiast
Enthusiast

Hi guan8,

Sorry if I confused your thread.  My assumption is that we won't be able to hide the "less impactful" fix, but still can hide the "more impactful fix".  Previously we only had the choice of major impact.

So my best guess is to address the lower impact, not implement the higher impact, and watch the alert go away.  But it is just a guess.  I'll refrain from future comments.

Good luck!

JoeA

Reply
0 Kudos
guan8
Contributor
Contributor

Oh, no, I'm sorry if I gave the impression your answer wasn't relevant. Your answer provides valuable and easy to understand information about the subject and a kind of "workaround" to the original problem. So I'm very happy you commented! I only meant to explain that the original question on how to hide the notification without any mitigation was still unanswered.

/Gustav

Reply
0 Kudos
AS102195
Contributor
Contributor

Any updates as to how we can mute individual VSphere Health alarms ?  For example like this one where we have accepted the risk.

matthewvanvoore
Contributor
Contributor

Also interested in the answer

Reply
0 Kudos
E5C6
VMware Employee
VMware Employee

I have several admins who are also interested in how to suppress the alert if they are willing to accept the risk.

nparas5
Enthusiast
Enthusiast

Hello There,

Just log a case with your hardware vendor HP, for this alert. They must have some upgrades like BIOS/Firmware for this. Mostly Both Vendors (Vmwar/HP) will ask you to upgrade to latest whether patches or firmware upgrades.

You will definitely get solution from them only. First try with HPE.

Reply
0 Kudos
schander007
Contributor
Contributor

these are the warning as to new esxi  6.7 they introduce second scheduler option to mitigate these CPU Venerability. go through these to understand the risk behind it.

https://kb.vmware.com/s/article/55806 - talks what is L1 Terminal Fault 

https://kb.vmware.com/s/article/55767- talk about performance impact .. like CPU hypertreading will impacted  and can be impact 30% less performance and you can't commit more vcpu to vm.

https://kb.vmware.com/s/article/56931- talks about the assessment tools to check what will be the impact on your environment if you mitigate this and use 2nd scheduler.

its your choice as per your environment to just ignore this warranting or implement the change and compromise with 30% perfomance on your enviorment.

Reply
0 Kudos
MCollauto
Contributor
Contributor

I am interested to the answer too: the main reason is that if you have a yellow alert that you cannot mask (and I was told by support you can only disable all the group), this can mask other issues that you wand to be immediately aware of (i.e. disk running out of space).

Reply
0 Kudos
wayne7215
Contributor
Contributor

We are in the same boat and need to disable this warning we get on all DL380 G9/G10 servers.

Is there really still no solution around for such a basic request?

HFMudd
Enthusiast
Enthusiast

I agree with wayne7215​ - I can't believe there isn't a way to turn it off, it's noise and impacting our ability to effectively handle events/alerts in our environment. Suggesting it's on HPE to provide a fix is not adequate if we wish to assume the risk we should be able to turn-off the alert.

Reply
0 Kudos
ChrisFD2
VMware Employee
VMware Employee

Why not just enable SCAv2 (if you're on the correct vSphere version)? You really aren't going to notice any difference in performance between having SCAv2 enabled or disabled - and the warning will be gone.

Regards,
Chris
VCIX-DCV 2023 | VCIX-NV 2023 | vExpert *** | CCNA R&S
Reply
0 Kudos
wayne7215
Contributor
Contributor

Yes maybe this would be just the quickest solution, but I don't want to take the risk of any performance issue, even the stats show up SCAv2 is better than v1, for a security risk we definitely can swallow and just because VMware is not allowing me to suppress a warning. How they will handle other warnings in the future we as customer would have to fix in their opinion? Do we will get as well notifications on every login for each security patch we have not immediately installed?

In my opinion customers should be allowed to decide which warnings they wanna get and which not, it's so easy.

Reply
0 Kudos
ChrisFD2
VMware Employee
VMware Employee

I thought I had replied to this via email yesterday but it doesn't appear to have worked.

The only way you're going to notice any difference between using full HT and having SCAv2 switched on is if your cluster is severely over utilised in the CPU area, in which case you have more pressing matters to concern yourself with than a warning in vCenter.

Regards,
Chris
VCIX-DCV 2023 | VCIX-NV 2023 | vExpert *** | CCNA R&S
Reply
0 Kudos