| Here's a more optimistic take which is unavoidably a plug. Urbit is maybe a sort of "extreme langsec." "Immune" is a dangerous word. Urbit is "premitigated" against Spectre for the following reasons, some cool and others stupid: (1) The Nock VM has no O(n) data structures, ie, arrays. This was not anything to brag about till now. (2) Urbit events are interpreted in their own process, which is one trust domain (one process, one "personal server"). (3) A personal server isn't a browser and doesn't habitually run code its owner doesn't trust. (4) Urbit is purely functional, so you only know the time if someone passes you the time. (5) Top-level event handlers are passed the time of the event. This is easy to fuzz. (6) If you are running untrusted foreign code, it is probably just a function. Giving this function a measured time interval from top-level event times would be strange. And it would need another channel to exfiltrate the stolen data. Never say never, but this combination of premitigations makes me worry about Spectre very little. Although, when we do have a less-trusted tier of applications (walk before run), ain't nobody is going to be telling them the time. Besides the plug, the lesson there is that one of the reasons Spectre is a problem is that langsec is an imperfect bandaid. Urbit is premitigated because it was designed as a functional system from the ground up. The JS environment is functional lite -- it allows typeless functional programming, but it also retains many mutable/imperative systems design tropes. It's these tropes that have become clever attack vectors. If you don't want to get Spectred, build systems that are formal and functional all the way down. |
Therein lies the rub -- if your program does not have access to precise timing information, it is by definition not operating at the full capability of the hardware which runs it. That's a hard sell to many domains.
Consider gaming. At 144Hz w/ 4K resolution you have 6ms to render a frame: that's about 1.3ns per pixel. If for a moment we imagine that it takes approximately 1 machine cycle per pixel to render a scene: that means you need to be operating at 1.3GHz just to meet the deadline for drawing to the frame buffer. -- That's before you consider memory & cache latency, or the fact that your multitasking OS is stealing resources for itself & other competing processes.
So no, one cannot just fuzz performance counters in the name of security. Any soft-realtime or hard-realtime domain is going to expect the machine to actually perform as advertised.