Hacker News Reader

Comment by theobservor | Hacker News Reader

The end result of these side channel attacks would be to have CPUs that perform no optimizations at all and all opcodes would run in the same number of cycles in all situations. But that will never happen. No one wants a slow CPU.

As long as these effects cannot be exploited remotely, it's not a concern. Of course multi-tenant cloud-based virtualization would be a no go.

View on HN

We need to drop all the untrusted code on some horrible in-order, no speculative execution, no prefetching, 5 stage pipeline from architectures 101 class core.

It might be preferable.

We have ridiculously fast hardware. In many use cases (client machines in particular) we do not usually really need that. I would gladly drop features for security.

It will also be good because users will become more annoyed when people try to sneak full programs into their websites, hopefully resulting in a generally less bloated internet.

If you account for all of the CPU "features" that can be exploited, you're looking at probably 80% of what makes it "ridiculously fast". If you also account for all of the ways in which the entire modern hardware ecosystem can be exploited, you're probably looking at gross performance loss of over 90% to remove these "holes".

An overclocked 486 PC that can only run a single program at a time and isn't continuously connected to a network might be very secure, but replacing every modern computer with something like it will not be even remotely feasible. In most situations, it would be better to have some risk tolerance, and couple modern hardware with mitigations, disposability, and supply-chain security instead.

If untrusted code includes JavaScript that would make Web apps ridiculously slow. (I know what you're thinking...)

Oh no, a totally unexpected side effect, less complex webpages.

> multi-tenant cloud-based virtualization

And that's why I'm not as worried about this as I was about the same vulnerability in Intel chips a few years ago.

There are a few cloud service providers that will rent you clock cycles on a rack-mounted Mac Mini, but not many, and even then they're for highly-specific workloads or build tasks. I suppose that's a problem for people paying far out the butt for that kind of service, but the vast majority of Apple Silicon devices are never, ever going to host cloud services.

This is why high core counts and isolation matter. Isolate the code to a specific core. Assuming everything is working as intended, an exploit won’t compromise other tenants.

Reply on news.ycombinator.com