[teh]

The original SES doesn't seem to do anything to prevent meltdown/spectre attacks [1]

This version removed direct access "Date" [2] but I'm not sure I'd trust any code running in the same process space given how hard it is to fix spectre in general.

[1] https://github.com/google/caja/wiki/SES#current-date-and-tim...

[2] https://github.com/Agoric/SES/tree/master/demo#taming-dateno...

[saurik]

What I really want is a JavaScript API--doesn't need to be a "VM": just a wrapper for an existing one--that makes it trivial to manipulate JavaScript engine spaces but where instead of them merely being separate memory allocators (as would be the case if you allocated two JavaScriptCore runtimes or engines or whatever they were called) the code is run in a separate process that doesn't contain any others memory or information and all communication with it is done via some kind of IPC (which you would then minimize using).

[colejohnson66]

> ...but I'm not sure I'd trust any code running in the same process space...

Can someone ELI5 how a separate process would fix Spectre/Meltdown?

[blattimwind]

Spectre relies on being able to speculatively access data and extracting information about said data through a side channel despite the speculative execution not committing. A separate process means address spaces are separate, which means speculative execution cannot access the data.

Meltdown is similar, but because a CPU affected by Meltdown does not perform permission checks during speculative execution, you can read memory that the execution environment doesn't even have permissions for. E.g. kernel memory.

The fix for Spectre is thus to only consider address spaces a security boundary; interpreters or JITs cannot be considerd security boundaries any more (in general).