The attacker is not a process running on the emulator, not even if you assume it is. Security is about the worst case, not about hit or miss partial solutions.
I’m talking about a hypothetical future where there are mitigations in place such as running each app sandboxed in an emulator. Obviously if a malicious process can sidestep any such mitigation and run any way it wants, then presumably it can read the memory of any process too? Why would an app even need to rely on vulnerabilities then?
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 targeting what an emulator is emulating.
> 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 to make it impossible to exploit speculative execution. It might run 1000x or 10000x slower than a modern JS engine however.
I need to reiterate that optimism ("remove all timing info...") has no place in information security.
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.
