I'm not informed enough to know if what I'm asking is ludicrous. Why does Cloudfare, Amazon, or some other hyperscaler ever build custom chips for running JavaScript. They could build in mitigations for these kind of shared resources attacks.
The problem isn’t JavaScript: To competitively run web app code written in any language, modern CPUs depend heavily on speculative execution, caching, and other complex, stateful implementation techniques that are inherently susceptible to side-channels. This is especially true when the only separation between attacker code and victim code is conceptual: Cloudflare is running them side by side in the same thread.
Since Cloudflare cares more about scale & throughput than single-worker performance, you could imagine security wins from a CPU design that forgoes modern stateful complexity wherever possible. Say, using a totally random cache replacement algorithm instead of the vulnerable LRU approach described in this article.
But the hit would be signficant, and Cloudflare is almost surely better off remediating the problems of complex hardware with software.
Unrelated to security, modern chips are designed with JavaScript in mind. ARM’s FJCVTZS is the most famous example. Broadly speaking, a custom chip for JavaScript would likely not be to improve security, only performance. ARM did try out something similar (in the broadest sense of the word) for Jazelle and later ThumbEE, which haven’t been around for decade(s) now.
Two fold: 1) there's no reason to think they wouldn't just introduce other attack vectors instead- and at least x86 and arm have a huge base of people looking at them 2) javascript doesn't statically compile well as such specialized hardware does not outperform x86/arm.
I'm not informed enough to know if what I'm asking is ludicrous. Why does Cloudfare, Amazon, or some other hyperscaler ever build custom chips for running JavaScript. They could build in mitigations for these kind of shared resources attacks.
The problem isn’t JavaScript: To competitively run web app code written in any language, modern CPUs depend heavily on speculative execution, caching, and other complex, stateful implementation techniques that are inherently susceptible to side-channels. This is especially true when the only separation between attacker code and victim code is conceptual: Cloudflare is running them side by side in the same thread.
Since Cloudflare cares more about scale & throughput than single-worker performance, you could imagine security wins from a CPU design that forgoes modern stateful complexity wherever possible. Say, using a totally random cache replacement algorithm instead of the vulnerable LRU approach described in this article.
But the hit would be signficant, and Cloudflare is almost surely better off remediating the problems of complex hardware with software.
Unrelated to security, modern chips are designed with JavaScript in mind. ARM’s FJCVTZS is the most famous example. Broadly speaking, a custom chip for JavaScript would likely not be to improve security, only performance. ARM did try out something similar (in the broadest sense of the word) for Jazelle and later ThumbEE, which haven’t been around for decade(s) now.
Two fold: 1) there's no reason to think they wouldn't just introduce other attack vectors instead- and at least x86 and arm have a huge base of people looking at them 2) javascript doesn't statically compile well as such specialized hardware does not outperform x86/arm.