We believe that this precondition is that the targeted kernel memory is present in the L1D cache.
Not only is L1D tiny, but stuff like prefetch doesn't touch it. So how exactly do you force any memory into L1D cache unless, like in all the examples we have seen, the victim program is pretty much accessing it in a busy loop?
I'll try to explain the small snippet from the paper. The exploit uses a Flush+Reload attack to use the cache as a side channel to leak memory read in speculative execution. They use a 256 * 4096 byte memory region to leak a 1 byte value from any location mapped to the process. 4096 is the page size and is used to make sure the caching doesn't create false positives. Data across two pages are not cached apparently.
Here's the example from the paper.
1: ; rcx = kernel address
2: ; rbx = probe array
3: retry:
4: mov al, byte [rcx] ; Read kernel memory(1 byte) into AL which is the least significant byte of RAX
5: shl rax, 0xc ; Multiply the collected value by 4096
6: jz retry ; Retry in case of zero to reduce noise
7: mov rbx, qword [rbx + rax] ; Access memory based on the value read on line 4
8: ; Note: The read on line 4 is illegal, but the CPU speculatively executes line 5-7 before this triggers a fault.
The receiving code then trys to access each of these 256 memory locations and measure the time taken. For one of them the value will be much lower since that memory is cached and thus that location is the value read. So if you read the value 84 on line 4 when you access the value at 344064dec(0x54000)in your memory it will be faster and you can deduce the read value was 84.
So in pseudo code the attack is
start = 0xFFEE // No idea if this is a reasonable start location
result = []
offset = 0
page_size = 4096
probe_array = malloc(256 * page_size)
loop {
flush_caches(probe_array)
read_and_prepare_cache(start + offset * 8, probe_array) // The above assembly
result.push(determine_read_value(probe_array))
offset += 1
}
There's an extra detail here about recovering from the illegal memory access in a quick way that I've skipped.
To answer the parents question I believe this only uses a single cache line(64 bits) since it only accesses a single value.
This is my understanding anyway, happy to be corrected
> You can force any memory into the cache so yes it's is read any physical memory.
Is there a direct method for that or do you mean that you can repeatedly try reading memory addresses until the address that you want to access is actually in the cache prior to your access?
The exploit is based on reading values that you shouldn't be allowed to access in speculative execution and then using the returned values to create persistent changes in the cache(they persist even after the CPU detects your illegal access). Those persistent changes are then read via a side channel attack.
So you read any address you want speculatively and then use the result to prime the cache in such a way that you can determine what the value you read speculatively was. This works because modern operating systems map kernel space addresses into normal processes and to make syscalls faster.
I'd recommend reading the paper[0], it's fascinating stuff.
It doesn’t force memory into cache directly. It determines values of bytes in memory by using the byte as a multiplier to an offset in memory. To determine byte value you can check all the offset combinations to see which was cached. Details in the meltdown paper.
We believe that this precondition is that the targeted kernel memory is present in the L1D cache.
Not only is L1D tiny, but stuff like prefetch doesn't touch it. So how exactly do you force any memory into L1D cache unless, like in all the examples we have seen, the victim program is pretty much accessing it in a busy loop?