Earlier quoted context omitted.
If this is your scenario, the attacker runs in its own emulator. A fairly thick pair of gloves, but not enough to prevent exploiting speculative execution vulnerabilities and reaching outside the emulator to poke into other processes. As another comment points out, attacks from Javascript code that escape the browser sandbox have been demonstrated, which is exactly your sandboxing scenario minus the easy part of targ…
> attacks from Javascript code that escape the browser sandbox have been demonstrated As far as I understand you still need to be able to have some kind of timing information or cpu state available in the sandboxed program, which is possible if the emulator/sandbox runs close enough to the metal (Such as a js program in a modern browsee, because they need to be fast). Remove ALL timing info and it should be possible…
If you think you have removed all timing information sources you are aware of, many remain: those you aren't aware of at all, those you failed to recognize as exploitable, those you didn't actually remove by mistake, those that are degraded but still present... The attacker should be assumed to be clever and knowledgeable; as the saying goes, creating a system that you don't know how to crack is easy.