Oh, but it does mitigate - just turns out it don't mitigate enough.

s/reservation/mitigation/ https://youtu.be/A-brgkkjnHc

Jokes aside - I understand the difficulty to adequately defend against meltdown/spectre. When the exploits were released I was running a service which definitely needed protection from this type of attack. Ironically we had just finished a set of optimizations that would have reduced our cpu costs quite nicely, the mitigations ate all those wins and more.

I guess I'm still bitter - I no longer own that system but it really frustrated me to hear that it apparently was still vulnerable to spectre style attacks.

> ate all those wins and more.

At least you still have a relative advantage: if you had not optimized, the CPU costs would have increased even more.

I turned them all off on all my production servers

they don't run arbitrary untrusted code and send a LOT of packets, those mitigations really hurt

That works on bare metal you control. If you rent something with VM / hypervisor the mitigations are important to protect from other VMs on the machine.

Mitigation between VMs is only effective when done from the hypervisor. Mitigations within a VM can only counter intra VM data leaks.

I think that's the smart thing to do. Default to safe, let people evaluate their threat model and disable as needed.

I'm curious, what options did you disable?

Add 'mitigations=off' to the kernel command line (assuming you're using linux)

We did it for most of our GCP images

Right, I'm not sure Spectre is worth worrying about outside of big multi-user systems, or a web browser executing Javascript. Otherwise if you're executing untrusted code, you're in big trouble regardless.