Apples's M1 has an issue too: PACMAN

[madires]

A new vulerability was found in Apples's M1. Possibly other ARM based CPUs are also affected:
- MIT researchers uncover ‘unpatchable’ flaw in Apple M1 chips (https://techcrunch.com/2022/06/10/apple-m1-unpatchable-flaw/)
- New 'PacMan' flaw in Apple Silicon is an echo of Spectre and Meltdown (https://appleinsider.com/articles/22/06/10/new-pacman-flaw-in-apple-silicon-is-an-echo-of-spectre-and-meltdown)
- PACMAN Attacking ARM Pointer Authentication with Speculative Execution (https://pacmanattack.com/)

[ataradov]

I'm not sure it actually matters, especially on a single user computers.

Meltdown and Spectre made a lot of noise, and are generally neat exploits, yet there is no evidence of them actually being used in a wild. And shared server applications where it could potentially matter hardened against them with various software measures.

I personally would pick performance over this type of security for the hardware I use.

[madires]

Yep, most users aren't really affected by this security issue. But it's good to know about this new attack.

[SiliconWizard]

True.

Now, most of the security issues found on modern processors are due to speculative execution one way or another.
While it's hard to just do without it (that would harm their achievable performance significantly), it seems even harder to get it fully secure.
I'm not even sure if it is at all possible.

[james_s]

I tend not to worry about this sort of thing. By far the most vulnerable attack vector in personal computers is the user. It absolutely dwarfs all of the various exploits.

[magic]

Now, most of the security issues found on modern processors are due to speculative execution one way or another.
While it's hard to just do without it (that would harm their achievable performance significantly), it seems even harder to get it fully secure.
I'm not even sure if it is at all possible.

The leaks of information produced in speculative execution occur by means of caches (like L1, or TLB in this case).

I imagine one potential mitigation strategy could be overprovisioning said caches and giving them checkpointing support, so that a speculative path that fails can undo all changes it has made to the cache. Speculative cache fills must be prohibited from evicting valid data and blocked until either the speculation is resolved or suitable cache line is freed/invalidated by somebody else.

The mechanism may not perform very well on caches with low associativity, like typical L1

Intel already support a remotely related mechanism which they call transactional synchronization extension. You can explicitly speculatively execute a piece of code and bail out of it if something goes wrong (it will also fail automatically if other core accesses the same memory at the same time). All memory changes are reverted. Cache state is not preserved, but the underlying implementation is often believed to work by means of creating a small "parallel reality" inside your local L1 and using the coherence protocol to detect inter-core data hazards.

Notably, it was disabled on several early implementations because of bugs. I suppose there is a lesson here about the difficulty of maintaining multiple alternate cache states in a multicore environment. Single core should be much easier.

[SiliconWizard]

As a side thought, as this kind of exploits IMO is much more problematic security-wise for servers than for personal computers, I think that might be a good idea to design CPUs made for servers with much simplified execution units (so very simple, or no speculative execution at all), thus with worse single-core performance per MHz, but with simpler cores with a lot less potential for exploits, and the possibility of putting more cores on the same die.

Implement the fancy (but almost impossible to get 100% secure) stuff for CPUs aimed at workstations and gaming systems.

[magic]

Workstations and gaming is one thing, but most consumer computers are spyphones and they need as much security as VPS farms do - all that "trusted computing", DRM, payments, etc.

[ejeffrey]

And shared server applications where it could potentially matter

However, pretty much any computer is shared because of JavaScript.  But this can be made mostly irrelevant for personal computers by hardening the browser JavaScript engine.

[Kleinstein]

Security relevant code is usually used only for a very small fraction of the time / code. Things could improve a lot, if the CPU could turn of features like cache and speculative execution for selected code / times.

The PC architecture is anyway not really suitable for a secure system - root kits / viruses that get effective at boot time before the main OS make the system weak. Ideally the security relevant parts would rund a separate CPU / memory from the main - user code. However this would requite a complete rethinking of the achitecture (e.g. sperate terminal and file system parts, possibly without an easy way to update / modify those).

As long as normal Windows / linux code is running those side channel vulnerabilites are more like a minor problem.

[ejeffrey]

Side channel attacks on the secure code execution are one thing and disabling caches and branch prediction might help with that but that isn't what the issue with what most people call speculative execution bugs.  That's where malicious code executing is able to read the memory or other state of the victim code even when it isn't executing.  To solve this you would have to turn off those features whenever executing any potentially malicious code.  That basically means everything.