CPU soft lockup: Watchdog: Bug: soft lockup - CPU#0 stock for 24s!

[Whatever]

Just to update everyone, I successfully stopped the softlockups by disabling mitigations in the host and in the client vm.

added this to the kernel command line in /etc/default/grub

mitigations=off

then ran

update-grub

Thanks for the help,
-Schmerbs

Take a look at this thread:
https://forum.proxmox.com/threads/p...ue-with-windows-server-2019-vms.130727/page-6

There are 2 posts from the dev team what to do to help them in investigating the problem

 

[HPmoss]

I read somewhere that turning mitigation off is not recommended.

 

[Schmerbity]

I read somewhere that turning mitigation off is not recommended.

I would imagine that disabling vulnerability mitigations is not recommended. That being said, simply "not recommended" is pretty low on any kind of warning system scale.

 

[t.lamprecht]

I would imagine that disabling vulnerability mitigations is not recommended. That being said, simply "not recommended" is pretty low on any kind of warning system scale.

This really depends on each setup, i.e., both their HW (= how much stuff one is vulnerable too), what guests are being run and who controls them.

E.g., for cluster that's only exposed internally, e.g., providing some infrastructure or CI system, where basically every guest trusts the other one, the practical impact of disabling those mitigations wouldn't be big.

But for a hosting service provider scenario, where one rents out virtual machines and containers to third parties, that have no trust relation between each other whatsoever, disabling those mitigations can lead to one malicious customer exfiltrating memory/secrets/... from another customer with guests on the same node, and so that might be even illegal depending on the jurisdiction.

 

[Schmerbity]

This really depends on each setup, i.e., both their HW (= how much stuff one is vulnerable too), what guests are being run and who controls them.

E.g., for cluster that's only exposed internally, e.g., providing some infrastructure or CI system, where basically every guest trusts the other one, the practical impact of disabling those mitigations wouldn't be big.

But for a hosting service provider scenario, where one rents out virtual machines and containers to third parties, that have no trust relation between each other whatsoever, disabling those mitigations can lead to one malicious customer exfiltrating memory/secrets/... from another customer with guests on the same node, and so that might be even illegal depending on the jurisdiction.

I would also add that if you are using a web browser inside a VM, there are known ways to exploit spectre through javascript, so you are potentially opening yourself up if you go to less-than-reputable websites.

 

[t.lamprecht]

I would also add that if you are using a web browser inside a VM, there are known ways to exploit spectre through javascript, so you are potentially opening yourself up if you go to less-than-reputable websites.

Browsers reduced the resolution of the timers available from JavaScript / web API after this became known though, so those attacks shouldn't be really possible anymore on any modern browser – but yes, they were possible initially, and there might be other vectors (in the future).. Sandboxing the execution of random JavaScript, WASM, ... while keeping high performance is really not a simple thing to do.