Tweet
Originally posted by markg85
View Post
I try and explain to people, that these exploits in the real word are not much of an issue, but they cry "but it can read unauthorised memory blah blah blah", they are in panic mode and not thinking rationally.
Malware authors go for low hanging fruit, and none of these exploits are low hanging fruit, they are difficult to pull off and all the test cases have been done with admin/root access already on a machine, in other words you need to be already compromised.
When looking as security one should always balance the pros and cons, do not just blindly apply every single security measure without thinking about it. One of the worse pieces of advise I often read is "always update your machine, its the number one thing you can do for been secure", that advice is given because its what computer illiterate users are capable of doing, its sort of like the old tech support "clear your internet cache and reboot".
The reality is these exploits are probably only going to be a problem for a typical end user if all other aspects of computer security get locked down, these are literally a last resort type exploit for malware authors, so one is basically throwing away large chunks of performance for maybe a decade in the future someone has a tiny chance of trying to use these exploits in the wild.
Its akin to spending $300 on anti ransomware software "just incase" you get asked for $200 to get your files back. The former is a guarantee, the latter is a extremely low chance maybe.
I find these tests really good, pretty much noone else has done anything like this, but what I would like to see is the impact of these mitigations one by one, so we can see if individual impacts have a reasonable level of impact that can be disregarded.
On proxmox qemu on a ivy bridge xeon host (has PCID but not NVPCID), I compared a fully patched system on its defaults against toggling individual mitigations. They were only toggled on the proxmox host I didnt bother to toggle on the guests as well which may make the results even bigger.
The result was in my case.
PTI on its own had a small but not ignorable level of impact, tasks on a guest dont take noticeably longer but do have higher cpu utilisation, on average 1.1 or 1.2x multiple on cpu utilisation so 10-20% more cpu cost.
IBRS, almost doubles cpu utilisation and makes things slower on the guest, absolutely trashes hypervisor performance.
l1tf on its default setting, makes compiling code on a guest take about 30% longer, cpu utilisation isnt much affected on low threaded workloads, but high threaded workloads like compiling are noticeably more expensive in cpu cycles. So e.g. on a pfsense firewall in a guest, it has pretty much no impact, but if you encoding stuff, compiling, that sort of thing, you will feel it. Disabling this on the host I noticed also disabled it on qemu, qemu auto appended the flag that disables it in the guest when I disabled it on the host.
Microsoft have clearly been uneasy about IBRS, they pulled the intel microcode from automatic updates and have recently announced they switching to the reptoline solution in a future build of windows 10, the microcode solution was never even offered to win 7/8 users at all. The reality is this stuff should not have been disclosed given there is no evidence ofit been out in the wild, and in addition to that patches should not have been deployed in such a rushed and panic'd manner, IBRS should never have even reached stable clode, reptoline should have been the "first" spectre v2 mitigation on offer, and things like l1tf should not be enabled by default as the benefit is very situational.
Comment