HN Explorer

14 comments

[ 3.1 ms ] story [ 34.8 ms ] thread
api
That's still really massive. It would only make sense in very high security environments.

Honestly running system services in VMs would be cheaper and just as good, or an OS like Qubes. VM hit is much smaller, less than 1% in some cases on newer hardware.

russdill
Look at it this way, any time a new side channel attack comes out the situation changes. Having this as a mitigation that can be turned on is helpful
bjackman
The next steps should make this much faster. Google's internal version generally gives us a sub-1% hit on everything we measure.

If the community is up for merging this (which is a genuine question - the complexity hit is significant) I expect it to become the default everywhere and for most people it should be a performance win Vs the current default.

But, yes. Not there right now, which is annoying. I'm hoping the community is willing to start merging this anyway with the trust we can get it to be really fast later. But they might say "no, we need a full prototype that's super fast right now", which would be fair.

Traubenfuchs
Sometimes something in me starts thinking about if this regularly occurring slowing of chips through exploit mitigation is deliberate.

All of big tech wins: CPUs get slower and we need more vcpu's and more memory to serve our javascript slop to end customers: The hardware companies sell more hardware, the cloud providers sell more cloud.

discardedrefuse
Sometimes its fun to engage in a little conspiratorial thinking. My 2 cents... That TPM 2.0 requirement on Windows 11 is about to create a whole ton of e-waste in October (Windows 10 EOL).
kookamamie
Windows suffers from similar effects when Virtualization-Based Security is active.
lenerdenator
Anything that runs on an ISA that has certain features has these effects, IIRC.
Eridrus
My understanding was that many of the fixes for speculative execution issues themselves led to performance degradation, does anyone know the latest on that and how this compares?

Are these performance hit numbers inclusive of turning off the other mitigations?

0cf8612b2e1e
Furthermore, if the OS level mitigations are in place, would the hardware ones be disabled?
bjackman
These numbers are all Vs a completely unmitigated system. AND, this is an extra-expensive version of ASI that does more work than really needed on this HW, to ensure we can measure the impact of the recent changes. (Details of this are in the posting).

So I should probably post something more realistic, and compare against the old mitigations. This will make ASI look a LOT better. But I'm being very careful not to avoid looking like a salesman here. It's better that I risk making things look worse than they are, than risk having people worry I'm hiding issues.

Eridrus
Not sure if you wrote this article and I appreciate an engineering desire to undersell, but if this is faster than what people actually do in practice, then the takeaway is different than if it is slower, so I think you're doing folks a disservice by not comparing to a realistic baseline in addition to an unmitigated one.
gddbvxmm
This week, Google Cloud paid out their highest bug bounty yet ($150k) for a vulnerability that could have been prevented with ASI [0]. Good to see that Google is pushing forward with ASI despite the performance impact, because it would benefit the security of all hosting companies that use Linux/KVM, not just the cloud providers of big tech.

[0] https://cyberscoop.com/cloud-security-l1tf-reloaded-public-c...

WhyNotHugo
When enabling this new protection, could we potentially disable other mitigation techniques which become redundant and therefore re-gain some performance?