Q: cpu flags security?

[Andreas Bochem]

According to the manual page for qm.conf in the Wiki (emphasis by me):

"VM-specific flags must be from the following set for security reasons: pcid, spec-ctrl, ibpb, ssbd, virt-ssbd, amd-ssbd, amd-no-ssb, pdpe1gb, md-clear, hv-tlbflush, hv-evmcs, aes"

At work, we need to specifically set sse4.1 or sse4.2 in our VMs, which are not permitted by this set. We have figured out already that this can be achieved either through the args section of a VM config or via defining a custom CPU model.

However, before we go on implementing either of this - we would like to understand:

What is there to know about "security reasons" if we activate those flags?

We haven't found a clue to this one yet.

 

[Stefan_R]

The set is limited to a whitelist because there are some CPU flags that can have security implications - AVX256/512 for example can stress the CPU very intensely, leading often to downclocking behaviour, and thus can cause performance issues on other VMs, even when scheduled to different cores. Some other flags might be relevant to certain side-channel attacks, SGX comes to mind (though I'm not sure that's supported at all in KVM).

SSE in particular is almost certainly fine to enable (not as heavy as AVX on the cores in modern chips, and only provides computing extensions, no system/platform management functionality), but also rather specific, and we didn't want to clutter the list too much either - the recommended approach here is creating a custom CPU model, as you already mentioned.

That being said, SSE is available in almost all emulated Intel or AMD CPU models, is there a specific reason you want to go with vendor-neutral kvm64/qemu64 (I assume that's what you're doing)?

 

[Andreas Bochem]

Dear Stefan,

thank you for your insights.

We have been using neutral kvm64 so far to avoid any hassle during live-migrations, no matter what (partial) hardware replacements might come to us in the future.

Is that not the best approach anymore these days?

best regards,
Andreas

 

[Stefan_R]

Only if you have a heterogenous cluster, so mixed Intel and AMD. Otherwise going for the lowest common denominator of whichever manufacturer you're using is usually better for performance while still having full compatibility.

Mixed Intel/AMD isn't really supported for live-migration anyway, although users have reported success in the past (along with a bunch of hard to diagnose bugs and weirdness).

 

[Andreas Bochem]

Thanks Stefan for the clarification in that matter. Greatly helps us with our future plans.