root cause of the meltdown and spectre vulnerability about meltdown-exploit HOT 8 CLOSED

I have a full exploit: https://www.youtube.com/watch?v=De4rBaAdKNA
It works very well on 7th and 6th generation of Intel CPUs.

from meltdown-exploit.

It just about racing with an access to the memory. While on some older archs it takes data to be in L1 cache to win it modern archs can be tricked into reading memory from the uncached memory, even if application is actively tries to keep data outside the cache (executes cflush in a loop).

Most likely there are tricks that can speculatively load data into L1 cache of a given CPU e.g. via some syscall. My exploit was intended as a reliable test (and is merged since to Linux Test Project) so I decided to go for a data that is guaranteed to be in kernel and can be read easily. Thus I read linux_proc_banner.

For detailed explanation on premises please take a look here: https://github.com/IAIK/meltdown/issues/9

from meltdown-exploit.

@paboldin
1、Can you explain in detail who races with who?
2、If meltdown poc can read any memory (cached , uncached), it must first succeed in fetching the memory from RAM( especially if uncached ) to the CPU cache . However, the privilege bit (if this bit works well in all memory loads, from L1, L2, L3, RAM ) verification in the page tables would cause the protection exception and forbidden CPU to do this, so how can this be exploited successfully ? Does CPU verify the memory access privilege and fetch the data to cache at the same time where racing problem may occur?
3、If meltdown can indeed read any memory area, does it mean that the instructions in out-of-order execution unit can do things without privilege verification before retirement? If so, when do the CPU handle these exception events afterwards and where do the CPU store these exception information?

from meltdown-exploit.

Memory access races with privilege check. Privilege check is rather slow as it requires traversing of page table (tree). So it is postponed until the access is done in Intel's CPUs (AMD claims to have no such vulnerability at all and it looks like true). By the time privilege check is done speculative execution already have read the data and accessed target array at the calculated offset. The thing L1 is virtually indexed so no page table traverse is required to access the data here and it is executed in parallel with the privilege check.

I have no theory on how it works for non-cached data. Probably, there is another speculative cache hit in play there.

from meltdown-exploit.

Also, please refer to the original paper for details: https://meltdownattack.com/meltdown.pdf

from meltdown-exploit.

Privilege bit and virtual-physical address mappings are in the same page table. Resolving a virtual address and check it's privilege can be done simultaneously. It doesn't make sense to say privilege check is slow because of traversing the page table tree.

from meltdown-exploit.

Yes. But once again: L1 cache is Virtually Indexed Physically Tagging meaning there is no need to resolve virtual address when accessing memory that is in L1 cache.

from meltdown-exploit.

@paboldin CPU translate a virtual address through MMU unit that would resolve where the virtual memory is in the physical memory space(cache, main memory, etc) and check the privilege. I suppose that these two action should always be carried out simultaneously. So as you said in the scenario of L1 cache fetch, only data value is cached in L1 while the privilege information is not cached? If not cached, then it makes sense that a racing situation can happen. If cached, there should be another deep reason for meltdown.

from meltdown-exploit.