L1TF CPU bug present and smt on, data leak possible

[runo10]

Hello everyone,

I will sell VMs for customers. My cpu is 2x2699v4. Do I need to turn off hyper threading for security? Or it is enough secure to use in debian in proxmox? This leak is known for 7 years. I thought there will be enough preventions for it. What is your toughts?

 

[leesteken]

If you use the kernel parameter mitigations=auto,nosmt, the Linux kernel will turn off Hyper-threading if it is necessary to be safe. The manual shows how to edit kernel parameters.

 

[runo10]

If you use the kernel parameter mitigations=auto,nosmt, the Linux kernel will turn off Hyper-threading if it is necessary to be safe. The manual shows how to edit kernel parameters.

thanks a lot. Actually I wonder which one is better to use on or of? If it is safe, using on is better probably?

 

[leesteken]

If it is safe, using on is better probably?

It depends on your work-load. It can give 5-20% extra performance or it can reduce performance a bit. This is not Proxmox specific and you can find peoples opinions and benchmarks on the internet.

 

[runo10]

It depends on your work-load. It can give 5-20% extra performance or it can reduce performance a bit. This is not Proxmox specific and you can find peoples opinions and benchmarks on the internet.

so you mean both is safe?

 

[leesteken]

so you mean both is safe?

I cannot say anything about that except what I said before: If you use the kernel parameter mitigations=auto,nosmt, the Linux kernel will turn off Hyper-threading if it is necessary to be safe.

 

[runo10]

I cannot say anything about that except what I said before: If you use the kernel parameter mitigations=auto,nosmt, the Linux kernel will turn off Hyper-threading if it is necessary to be safe.

Actually it looks like better ht on for me for many vcpu more than core/thread count. But I wonder what is trade off or is it safe leave it on

 

[JensF]

If you want to be on the safe side, use the kernel parameter Leesteken described. Always asking the same isn't helpful and speculating will not help too!

 

[runo10]

If you want to be on the safe side, use the kernel parameter Leesteken described. Always asking the same isn't helpful and speculating will not help too!

Just saying to be safe side, turn off is not an answer to my question. If you dont know anything, dont answer then. Always answering the same fact isnt helpful. So turn off safe, turn on unknown or what. I know this too. But question is about what is trade off on multi vcpu virtual machines or is it enough safe to turn on. You both dont know anything about it is safe or not safe to turn on, am I right? Also you dont know nothing about multi vcpu case? Also no experience? just saying known facts useless. Why the people here are so aggressive? My question is very clear, if you dont know dont talk then. Or dont complain about that.

 

[JensF]

Then just use

lscpu

on the console and scroll down to the "Vulnerabilities".
If you see some lines with "Vulnerable" then you know...

 

[runo10]

Then just use

lscpu

on the console and scroll down to the "Vulnerabilities".
If you see some lines with "Vulnerable" then you know...

yes vulnerable but there are mitigation

I find this:

Core scheduling's main goal is to prevent side-channel attacks that exploit shared CPU resources, such as the L1 data cache. These attacks are possible when a malicious process from one VM runs on the same physical core as a process from another VM.

The kernel scheduler handles this by grouping all tasks from a single VM into a "trust group." It then ensures that all the threads on a single physical core (both SMT/Hyper-Threading threads) are running tasks from only one of these trust groups at a time.

So this means I think, VMs are seperated with mitigations. Probably inside vm processes are vulnarable to eachothers. Or there may be mitigations for them too.