Not too much discussion two weeks ago when the paper was posted on HN , so I will raise a point I've made before  and is consistent with the recommendations of the paper (and another post in this thread ): this is an opportunity to improve the terminology, mental models, and formalisms of observable state, and its implications for information hiding, privilege separation, and computer system design.
This conversation needs not only to occur among (e.g.) computer chip designers and cryptography experts, but also among higher-stack users of that technology, so that the information leakage aspects and trade-offs can be analyzed together with other performance indicators of the system.
It seems as if the haphazard, ad hoc way that chipmakers and system architects dealt with this issue have contributed to an environment where Spectre could occur: and such timing attacks were never a secret, but resistance to them in various levels of mainstream computing appears to have been fitted in a patchwork of hasty fixes and well-meaning but informal caution. The conversation around this topic could use an upgrade, and the paper's authors agree.
 https://ts.data61.csiro.au/publications/csiroabstracts/Ge_YC...  https://news.ycombinator.com/item?id=19547293  https://news.ycombinator.com/item?id=17308014  https://news.ycombinator.com/item?id=16165942  https://news.ycombinator.com/item?id=19644997  https://news.ycombinator.com/item?id=19670296
Who might that market be?
(Although they tend to be very bad at threat modelling)
Although, it kind of seems like, the more expensive you digital assets, the more you just need to a) hire a full time security person and b) insure your asset.
I'm not sure how a new OS would fit into that.
It seems like it would have to be people WITHOUT a lot of assets who would be the initial customers. People who can't just pay a security person to go over their images.
So maybe casual crypto users.
But wouldn't they be better off just with a custom dongle? A dongle isn't running untrusted software.
Also, isn't part of this technology that it squeezes a little more performance out of a machine without leaking information?
That takes me to the comment below... cloud hosting platforms.
Most of these vulnerabilities come from speculative execution impacting a shared cache.
Cloud providers who target security-sensitive users who also don't have a lot of money (to just pad the hardware budget) would be ideal.
Or the cloud vendors could start offering compute running on new, more secure hardware - e.g. special VM types marketed accordingly.
I personally think that these performance drops leads to a horrific environmental impact because every performance drop means that more hardware needs to be provisioned and powered to counter it. So this directly results in more toxic waste from these elecronics and a higher carbon dioxide output into the atmosphere (cloud data centers are a major consumer of electricity). Compared to the long term impact of that, a extra few security breaches sound like the lesser evil to me personally.
Fundamentally, the need is for a completely different model of computation to abstract away time-channel leaks. This cannot be fixed by patching existing software and hardware, and we're going to go through a lot of pain and anguish trying. As another comment points out, the well of possible timing attacks is infinitely deep (attached hardware, network performance measurements, etc.).
The two options are performance or security, pick one. It seems the industry is trying to pick both, and it's going to take us a long time to realize that we're going to get neither.
For clarity - my proposal is segmenting hardware and software products between the two categories of "general purpose, trusted computing" and "safe for shared hosting." The 2nd category is so small compared to the first, it seems unfair that its domain-specific problems should hamper the rest of us.
 Thanks to a combination of reasonable software mitigations (unprivileged lower-resolution timers) and that most of these attacks require arbitrary code execution in the first place
If a normal user is using a web browser and one tab has their bank information, and the other has a suspect website, then you have to be concerned about sharing resources and security.
Alternatively, run them at an isolated context with no
websockets, limited access to timing (second or two precision - a lot sampling needed), limited CPU and memory utilization, no sound, no GPU acceleration [likely another large side channel surface], etc. Ahh yeah and delete all their cookies while we are at.
Then you can give your (trusted) native applications all the available resources without artificial constraints.
(of course this assumes you see most native applications as trusted, but personally i see any alternative as too Orwellian to get behind)
> Thanks to a combination of reasonable software mitigations
That is time protection. Restricting access to system timers wasn't enough here; mitigations also need to prevent user-created high resolution timers, so useful features like SharedArrayBuffer had to be disabled, to prevent the creation of synthetic timers.
> The two options are performance or security, pick one.
That is not the findings of the paper: "Across a set of IPC microbenchmarks, the overhead of time protection is remarkably small on x86 [1%], and within 15% on Arm."
I think if there's a segmentation to be made, it's "general purpose, untrusted computing" and "trusted high performance computing". The second category would be the reserve of such projects as physics simulations and render farms.
or smoothly scrolling, 60fps rendered canvas apps in browsers. I think there can't be an apartheid between untrusted and trusted, because developers would push the user to make their software trusted to get the max performance (and the users would just agree).
I don't see it going this way. This is comparable to virtual memory and MMUs. When there is support in hardware, the speed benefit of not using it is negligible (as shown by the 1% difference demonstrated in the research).
When it is not needed, there is a benefit of not implementing it in hardware, and saving power and die area. For example, GPUs (traditionally) and crypto mining hardware do not employ MMUs.
Isolation between apps on mobile phones is really important. That's a huge part of the computing landscape in terms of number of devices deployed, and falls within the 2nd category. I don't think it's realistic to dismiss so easily.
Getting this to work in raw Linux may be hopeless given the breadth of the kernel data, but they have smart devs, so maybe they'll figure something out.
And Rob Pike said systems research is dead. Ha!
We might see this issue as an opportunity. That is, by thinking about a concept called "time protection" we expose all these things subsystems are doing and make them easy to argue about. We can now say "Oh good, XYZ improves best-case speed, but sadly it also compromises time protection".
Having such a language means the industry can slowly start improving these things rather than sweeping them under the rug. It will not stop the improvement from being slow and difficult.
And there may even need to be a third part. An understanding that nothing can be fully protected.
I wonder when programming languages will start factoring out the ability to check system timers. Some capability-aware languages have already done so.
I don't see handling this at the programming language could help, and I think that whether timing is privileged or not is built into CPUs so there's nothing we can do about it, but this seems plausibly acceptable to deal with speculation. Permit speculation, but make it privileged to detect if speculation occurred.
(Not sure why this is wrong, but confident it must be.)
However, I'm not sure how much merit this argument has since very few applications even bother with this level of protection but need it.