OSDev.org

Korona wrote:That justs introduces a races condition between the timing measurement and the invalidation. It makes the attack harder but not impossible.

Well, i guess each core could have a completly separate cache, so that timing is impossible in parallel with the read and invalidation. Not sure how this would affect performance though.

mariuszp wrote:Could they perhaps fix both Spectre and Meltdown in hardware by simply deleting the results of speculative mis-execution from the cache, just like they are deleted from registers?

Then you can probe the other way, load both data into cache and see which cache get deleted.

PS. nothing is deleted from registers, they are just discarded by not aliasing them. Furthermore, meltdown confirm that the intermediate values in the register files are indeed used for subsequent speculations.

mariuszp wrote:If there was something already in that cache line then Spectre woudl not have worked anyway, so that case can be ignored.

No, Spectre works when the branch cannot be concluded (say, rely on A not in cache), and produce side effect on B.
By (naively) invalidating B itself is a side effect that can be measured. Even with a complex logic to revert the cache state (ie. invalidate only if its fetch by SE), it still create side effect which some other thing is evicted, and may be measured in theory.

Is there a way to reliably predict what got evicted though? Especially since different CPUs have different cache sizes, and may have different eviction strategies (which likely vary way more than loading data into the cache). It probably gets even less predictable if the CPU decides to reorder cached writes to get better bandwidth (by writing to consecutive DRAM addresses which should have a much lesser time penalty than random access as far as I know).

Sik wrote:Is there a way to reliably predict what got evicted though? Especially since different CPUs have different cache sizes, and may have different eviction strategies (which likely vary way more than loading data into the cache). It probably gets even less predictable if the CPU decides to reorder cached writes to get better bandwidth (by writing to consecutive DRAM addresses which should have a much lesser time penalty than random access as far as I know).

You don't need to know what get evicted, you just need to know something had evicted. You don't even need to know the CPU cache size.
My thought experiment:
1. fill the cache with your array (this should be larger than actual cache size)
2. run offending code
3. read the array

some entry will get evicted anyway to run the code, but one branch will evict more (you can evict a big chunk in the speculated branch by loading multiple chunk of memory into registers), thus yielding different timing on (3)
This may involve very complex logic to pull out the attack, but in security perspective the door is already opened.

PS. Project Zero paper says the speculation execution can be prolonged to milliseconds ahead by purposely pollute the predictor, caches and other performance boosting units or just write code with badly stalls. This create an easy opportunity to make significantly measurable effect on the "bingo" branch.

Well then, is there any possible solution at all other than completly removing speculation (which would be a performance disaster?)

Perhaps it doesn't really matter, as long as scripting languages and such can be properly secured. After all, binary code in a process reading its own memory through Spectre won't be a problem since it can read its own memory anyway.

Well then, is there any possible solution at all other than completly removing speculation (which would be a performance disaster?)

VLIW maybe?

mariuszp wrote:Well then, is there any possible solution at all other than completly removing speculation (which would be a performance disaster?)

Perhaps it doesn't really matter, as long as scripting languages and such can be properly secured. After all, binary code in a process reading its own memory through Spectre won't be a problem since it can read its own memory anyway.

An application like a web browser should be able to request the kernel to mark "cache-disabled" memory pages containing SSL-encrypted webpages, or user/password login information. There are bits for that in the page table entries.

In this way all something like Meltdown/Spectre could ever read would be binaries already on disk and non-critical stuff, because the critical pages would never be cached and then there would be no cache vulnerability for that data because it would just never be present in the cache that another program could try to leak inter-process.



I suspect that this would be an ideal solution because:

- It assumes that the cache needs to be treated securely regardless of CPU flaws.

- No operations that reduce efficiency would be used in this step, only marking individual pages cache-disabled as requested by the application itself, which knows where critical data would be as to indicate what to disable from cache.


But it would need to be tested to see how well it goes, to provide a kernel API that allows user-space programs and kernel drivers to specify to the kernel which pages to cache-disable for security or efficiency reasons.

~ wrote:An application like a web browser should be able to request the kernel to mark "cache-disabled" memory pages containing SSL-encrypted webpages, or user/password login information.

You won't design kernel or CPU around a specific use case.

Also, how about other non-critical information that not marked by "cache-disabled" pages, like key stokes, browsing history, website accessing cookies on other websites (session!), the list goes on. At the end you reached a point either no one care, or you have fully disabled cache - which is slower than running in full emulation like bochs.

Cache enable/disable per page is a feature available to many types of CPUs, so it is a valid resource that would be intended for a case like this.

It's the same, but as you can see with cache-disable / enable capability exposed to any program for its own memory, the program just needs to decide what to protect more. It's easy to update for all browser and OS vendors.

All the examples you have mentioned are data that is accessed very infrequently, and they all are low-speed data, so if you wanted to configure your browser to protect all those things by default it would make for an efficient solution using only the basic protection features of all 32-bit CPUs since the 386 (selective cache-disable of pages as requested by each application).

Many of those data are in the disk anyway, but they should be possible to protect in this way at the CPU level.

Oh and I shall repeat once again. For meltdown and spectre, the sensitive information does not need to be in cache, they only need to be addressable. Did you read and understood the issue?

I've read the cases, they always mention the cache, or trying to load currently non-present data into the cache.

It never mentions a case where all involved data is cache-disabled.

That's what makes me think that a cache-disabled single page would be invulnerable because all accesses to it would be performed directly in RAM, never in the potentially spillable CPU cache.

OK let me explain to you why cache over sensitive information is irrelevant, consider the meltdown case:
On line one you access a faulty address, due to a bug in CPU, the permission is checked in async manner, exception will fire upon the instruction retire. Inside the CPU, that instruction will be break up into micro-op including 2 operations: fetch [kernel_address] into register file, alias result to rax. This instruction will run (and cause exception) with or without cache enabled.

Now with speculated execution, the following 2 lines will get executed, and using the internal register file even rax will get discard later (by not aliasing to rax). With [user_address] cache enabled, such speculation will cause a cache-effect on the user data.

Long time later you handle the exception gracefully and return rax = 0, then by checking if [user_address + 0x100] is in the cache you deduce if the bit is one.


The only way (in this direction) to totally avoid this is disable cache over [user_address], which is impractical.

The Boundary Check Bypass CVE works similar way and you cannot protect by disable cache over sensitive data.

~ wrote:I've read the cases, they always mention the cache, or trying to load currently non-present data into the cache.

It never mentions a case where all involved data is cache-disabled.

That's what makes me think that a cache-disabled single page would be invulnerable because all accesses to it would be performed directly in RAM, never in the potentially spillable CPU cache.

The attacker allocates THEIR OWN memory, which they load into the cache. The data you are targetting does not hve to be cached at all.

But your data will be marked cache-disabled.

A cache effect would happen in the registers, but I've never heard that a cache-disabled page would ever get loaded in the cache, it would have no reason to be cached, it would never be used anyway from the cache if it's cache-disabled and it would be too poor of a design if we think that pages could be marked like that because they will be used for DMA, so caching would waste resources for nothing.

It would be like saying that fully disabling the cache would still allow memory leakage through processes. That makes me think that if we cache-disable each page with the bit for that in their individual entries, then the actual contents of those pages won't be leakable because they won't be copied to the cache, at most the registers and addresses could be deduced, but not the cache-less-marked pages' content.

That's the case I've never read in the documents, it never claimed being able to dump cache-disabled pages, I found no occurrences about it, probably I should convert it to audio to see if I can find a case about successfully dumping cache-disabled pages, but I think that it's not possible, but untested because a kernel that exposes the capability to mark pages cache-disabled / enabled seems to be very rare, but now more necessary, and not really treated with here.