So the same answer as before?

The "If we play very hard with user browser we can sometimes get something out of user browser. We do not know what that something is, we need to know what kind of a system user has, we should profile profile it, etc." is not impressive as a demo. I cannot make it work under a Debian 10, Chromium and i4970K and i7-6500U. This not not Elon Musk throwing a brick and brick breaking a windshield. It is not having bricks to throw.

The demo is "Pull up website A into a tab 1. Go to website B in a tab 2. Website B says 'You have website A' opened". That's a demo.

> The VM ones don't really have anything to do with it being a VM. Being a separate VM just doesn't save you.

If that's the case Google should be able to develop an demo attack where content of a file in a VM A be readable in a VM B in a jiffy.

These are timing attacks. They're heavily dependent on the specifics of the target. The code has to know what it's measuring in minute detail, because the timing is affected by nearly everything. The exact instructions being executed by the target program, the size and associativity of the processor caches, everything.

That doesn't mean you can't do it. It does mean you can't create a generic exploit that works against all software and all processors, instead of one targeting a specific application on a specific model of CPU. Then people say "it doesn't work for me" because they're using different code or hardware and the code has to be tailored for that, which is work, which nobody is going to do for free to appease hecklers.

> If that's the case Google should be able to develop an demo attack where content of a file in a VM A be readable in a VM B in a jiffy.

In a VM doing what? It can't just be idle. It has to be executing some code whose timing you can measure to extract its secrets, and the secrets in the address space of that process have to be useful in order to get the file, e.g. a password that can be used to sign into the VM. Then the exploit has to be tailored to that software and hardware.

The fact that nobody is willing to do this over a message board post is not proof that nobody can do it if there was a few thousand dollars in it for them. These exploits are not the low hanging fruit; that isn't the same thing as being impossible.

> These are timing attacks. They're heavily dependent on the specifics of the target. The code has to know what it's measuring in minute detail, because the timing is affected by nearly everything. The exact instructions being executed by the target program, the size and associativity of the processor caches, everything.

So they are absolutely positively irrelevant in the real world.

> In a VM doing what? It can't just be idle. It has to be executing some code whose timing you can measure to extract its secrets, and the secrets in the address space of that process have to be useful in order to get the file, e.g. a password that can be used to sign into the VM. Then the exploit has to be tailored to that software and hardware.

So again, they are absolutely irrelevant in the real world.

Security industry became an industry of chicken littles. 99.9999% of modern attacks are attacks that were executed successfully because someone was running the code that had sql injections, direct variable substitutions before doing sytem, lack of user input sanitation and validation, or pulling yet another multi-gigabyte unaudited pile of junk dependencies a-la left-pad.js, not because someone mounted a timing attack. Except that dealing with those issues is not sexy so instead we are getting everyone freaking out about some internet villains doing something ( that no one else can do ) to CPUs of a random Joe ( the villains knows everything about Joe's machine and processes running on it and can even control it ) to mount a sophisticated attack, never mind that he can just make Joe install a piece of code that will run with elevated privileges for 0.0001% of the effort.

This is why execs are considering security people to be snake oil salesmen.