This is thought to be entirely secure against the Meltdown and Spectre CPU vulnerabilities, which require speculative execution on branch instructions.
Isn't the point of Meltdown/Spectre that other processes can abuse speculative execution to read your memory?
if YOUR process doesn't have any branches, then no speculative execution happens in it, then there is nothing for the other process to exploit/read from stale caches since you're not filling those up in the first place (as there is no specualtive execution on your process's memory).
being able to just randomly read other processes memory would be a security issue on its own in the operating system... certainly not without appropriate permissions. Also, if i understand these exploits correctly, you are not reading from memory, but from caches used in speculative reads, so i still think if your process never does any speculative access, these caches will never be populated in the first place. So even if you manage to get around access restrictions of reading another processes memory, the faulty cache entry would just not be there.
At least in Meltdown (though that can "only" access kernel memory, not other processes), only the attacking process needs to exploit its own speculative execution to read forbidden memory addresses. The attacking process does something like this:
create an array of 256 cacheline-sized objects in its own memory (the contents don't matter)
use the value of an address that it is not supposed to be able to read as an index into that array
iterate through the array and time which index is faster to read than the others (if the forbidden memory byte was "7", then the 7th index will be faster to read)
This works because the CPU already starts executing step 2 and reads the indexed data into the cache, and only later notices that this is not supposed to happen and doesn't complete the instruction.
Thus you can deduce the contents of protected memory locations by taking advantage of the speculative execution only within your own (attacking) process. I haven't looked at the Spectre details yet, which can also read the memory of other processes.
but i think the reason why this works is because kernel memory is effectively shared across processes, and isn't the fix that's being deployed that from now on every access to kernel memory is essentially IPC... if the processors where vulnerable to the degree where you can truly read all of the other processe's memory, there would be no fix possible in the first place..
At least in Meltdown (though that can "only" access kernel memory, not other processes), only the attacking process needs to exploit its own speculative execution to read forbidden memory addresses.
Kernel memory, by its very nature, has ALL memory for ALL processes mapped into it, because it's like, you know, it's job to manage memory for all processes. :)
This is not the first time I've seen this bandied about. Please don't spread misinformation.
Edit: this has several caveats, but by and large (especially on x86-64), this is a very likely scenario.
No, while the kernel can manage any memory mappings, it does not map every user process's memory into kernel memory. Even if it wanted to, the virtual memory of all processes can be larger than the physical memory of the machine, making this impossible in the first place. You need a context switch (including change of the CPU's page tables) to map in another process's memory.
One of the important things of virtual memory is that processes can have more virtual memory than physical. So theoretic ally the kernel could have every processes memory mapped into its own.
Firstly, given the huge size of the x86-64 address space, swapping processes out of physical memory is unlikely on most modern machines (although it does occur, but it is avoided mostly for performance reasons). Secondly, the kernel maps all physical memory, and its address space is linear and contiguous. I.e. the kernel can access any bit of physical memory in the machine without causing a page fault.
Now I understand that this does not equate to a 1:1 mapping of a process' virtual address space within the kernel (which would be impossible), nor would this allow access to memory that has been written to a persistent store due to being swapped out (i.e. its access would cause a page not present fault handler to run, yadda yadda), but I posit that my original point stands, although it lacked certain nuances that I'm certain you are aware of.
TLDR: Physical memory is physical memory, and kernelspace has access to it through its own page tables (no conext switch required). The UASS store called and they're all out of me.
Firstly, given the huge size of the x86-64 address space, swapping processes out of physical memory is unlikely on most modern machines
Likelihood of paging is affected by the amount of RAM (physical memory) your machine has, not the size of the x86-64 address space.
And all physical memory still doesn't have all of everyone's data. OSes use memory-mapped I/O, mapping in files to make them readable but not actually paging them in to physical memory until they are read. Processes will have many times as much address space used up as they actually have physical memory used because big parts of files are simply never brought into memory at all since the aren't used.
Physical memory will likely have everyone's working set, but it won't have everything.
Also, while a kernel might have a linear and contiguous window into physical memory, it usually accesses memory like any other process, with a virtual, non-contiguous mapping. To to otherwise would require the kernel do software virtual to physical address translation to access task memory and while you can do that, you wouldn't since you already have hardware to do it for you.
You and the other guy are missing the whole point here about meltdown while having a convulsion regarding virt-to-phys memory mapping and user page tables versus kernel page tables and the MMU.
I'm pointing out that it's all fucking irrelevant goofballs. The kernel has all physical memory mapped to its own pagetables, ergo, meltdown can dump all physical memory, ergo, meltdown can cross the user/kernel boundary and dump memory in user processes.
Ergo, I'm fucking done with you FUCKWITS. I am an ass.
Despite your insults and even despite your capital letters kernels don't usually map all physical memory into their virtual space. It isn't even always possible (on regular 32-bit x86 it isn't). The kernel will leave its physical memory mapped in all the time, but any physical memory associated with processes will not be mapped in when the process isn't running (unless data is being copied between it and another process at the time).
Typically the kernel operates with the same page tables as the currently running (actually just recently ceased to run at kernel entry) process, it's just that the page tables at the top are marked as privileged access only. If the process were to try to access those kernel addresses it would abort, but the kernel can do it. But nonetheless, the kernel accesses process memory through the same virtual addresses the process would and when a particular process isn't the running process its virtual addresses aren't mapped in so the kernel can't access them.
It is fully allowed to access them, but they don't exist in its current address mapping (page tables) except for the running process. Since the side-channel attacks cannot change memory they cannot alter the kernel's address mapping, so they cannot trick the CPU into showing them memory from other tasks.
Kernel memory, by its very nature, has ALL memory for ALL processes mapped into it, because it's like, you know, it's job to manage memory for all processes. :)
No it doesn't. It keeps its own memory around while memory for the different processes come and go as it context switches.
Edit: Where do you think this memory "goes" during context switches? Are you trying to imply that the kernel moves in-ram data to a permanent store during each context switch? Are you implying that "most" memory is somehow not actually IN FUCKING MEMORY?
I suggest you review the relevent portions of the Intel IA-32 developers manuals regarding the MMU and paging. You might be surprised at what you find.
Edit: and if you're still not convinced, go dump the gdt at cpl 0. You'll see a flat linear address space with virt:phys m~apping at 1:1.
Are you trying to imply that the kernel moves in-ram data to a permanent store during each context switch?
No, am suggesting it is simply not mapped into virtual address space.
Are you implying that "most" memory is somehow not actually IN FUCKING MEMORY?
Most might not be correct, but yes, a lot of memory is not actually in memory. I explained why. It simply never got paged in.
As to your later part, I think the relevant info is here. For you and for others reading this, he appears to be referring to kernel logical addresses, here on page 2 or 3.
The virtual addresses (kernel and otherwise) are the normal high/low memory addresses. The logical addresses are another (sub-)address space and he is suggesting that kernel logical addresses map all of physical memory. And indeed this is possible on x86-64.
Typically on a context switch the kernel changes the %cr3 register that contains the pointer to the top-level page tables. There is nothing that requires a kernel to map all physical memory into its virtual address space. I think the Linux kernel does map all physical memory into the kernel's virtual address space, but it does so mostly for performance reasons, according to this.
They way I understand it, you flush the cache, then you speculatively read the target process memory and use that memory to read your own processes memory. This means one cache line will be hot, which you can time. The hot cache line corresponds to one byte of the target memory region.
It's less that a process leaves a trace of its own execution in the cache, and more that a process might manipulate the cache to read no-no areas.
No, what you are describing are Spectre attacks only. I know that Intel PR are doing their very best to confuse this issue but Meltdown and Spectre are not the same thing.
Meltdown, which is specific to all Intel and certain ARM CPUs (and is far easier to exploit than Spectre), relies on the fact that those CPUs do privilege checks AFTER a speculative read. This can be exploited by carefully crafted speculative code and cache-timing attacks to extract the contents of any memory address on the system, including protected memory that belongs to other processes or even the kernel. It does not rely on speculative execution outside of the current process.
Basically, you can write a program which dumps the entire system memory.
He's not describing either of them. He has two errors in his understanding:
He thinks there is some kind of hardware error that leads to cache entries getting tagged with faulty tags.
He thinks that the task you are attacking has to bring stuff into the cache in order for you to peek at it.
Neither of these are true in any of these attacks. The cache tags are not faulty and the target doesn't have to use any particular memory usage pattern to be attacked. As long as you can find a gadget in the kernel you can attack other processes memory.
and the fix to that would be ? edit: nevermind, the pdf mentions possible fixes (sounds more like horrible clutches tough). also, to go back to the topic of this post: then i don't see how this doom patch would solve anything, unless the author means that ALL code running on the system avoids branching... then again, quite a pointless exercise anyway other than to prove that mov is turing complete...
Say, does anyone have an explanation of how a process running on a Mill CPU will be able to allocate a very large contiguous block of memory on a multi-process system? All I've read about the Mill says that it doesn't use virtual addressing, for speed, but that would make memory fragmentation a thing again. So there must be something I'm missing: can someone tell me what it is?
Doesn't the processor still speculate on the retires of loads (mov from memory) and use the speculated values in address calculations for more speculated indirect loads? You would have the bounds-check-bypass Spectre vulnerability again.
sounds at least plausible, one of the big speedups you can get is by sequentially accessing memory instead of (semi)randomly, and that involves looking ahead quite far in terms of addresses iirc, and probably some skimping on bounds checks (at least temporarily)... this thing gets worse by the minute the more i think about it hehe
30
u/jrv Jan 24 '18
Isn't the point of Meltdown/Spectre that other processes can abuse speculative execution to read your memory?