Sorry, this does not make much sense. Why would you need a timing attack to read memory from your own address space? Just a regular code execution exploit should do it.
Here, I found the relevant info (that I was too lazy to find before I posted my first comment, apparently):
> While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.
If you're making a VM such that the running code can only access a particular array, Spectre allows a timing attack that can get malicious code in the VM access to the full memory space.
You're right that it's not that scary for most use cases. What it really means is that it's hopeless to make memory inaccessible to a sandbox without putting a process isolation barrier betwixt the two, as there's no real way to close out all of the timing attack possibilities. In principle, if the only thing you needed to foreclose was memory vulnerabilities, then sufficiently good programming™ would let you have the sandbox in the same process space; as a matter of practice, though, anyone looking at product security seriously would still make you put in process isolation, because that kind of good programming just doesn't exist at scale yet.
(Note that Meltdown, but not Spectre, allows timing attacks that cross process isolation domains.)