4 ms·

> can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM? From what I understand, it doe

> can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM? From what I understand, it does happen on AMD, which is why AMD CPUs are not vulnerable to the more dangerous Meltdown attack (any code reading kernel / hypervisor host memory). Intel / ARM delays the checks until later, to the time when the speculated instructions are actually finalised and make their results available. This is faster, and loading some memory into the cache is normally invisible to the unprivileged code. The checks would still be done when actually reading that memory. But nobody spent enough time considering the timing side-effects of the cache. Now even if the protected memory reads are fixed by the OS updates - then it still leaves the Spectre attack - code running in a process reading all of "its own" memory, regardless of any software sandboxing. This means that all sorts of sandboxing methods for javascript interpreters, bytecode interpreters, plugin architectures, etc are insecure. And the OS patches can't help here, because the sandbox isn't in protected memory.

zackmorris 9y ago
Thank you, that was a succinct explanation of the difference between AMD/Intel and the order of speculation and protected memory access check for the Meltdown attack, and makes it easier to understand: https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability) https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili... I see now why the Spectre attack is so serious (reading out of bounds within the same process memory). I feel like there may be ways to catch unallocated memory access similarly to how protected memory works. But, that wouldn't help reads from allocated memory in runtime environments like for Javascript (where separate scripts in the same process space aren't meant to see each other's data). This is clearer to me now: https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit... Going forward, we may have to assume that security is only possible with true process isolation. For example this might put pressure on OSs to fix their slow context switching implementations to encourage the use of processes instead of threads. Beyond that, I can't see any easy way to fix the situation and am highly skeptical of things like compiler fixes, because there will likely always be another way to abuse various instructions to read outside memory boundaries.
- tathougies 9y ago
  The slow context switching between processes has nothing to do with OS implementation. True context switching involves a page table flush. This is slow due to caching, independent of the OS. The only thing the OS can do is tell the processor which parts not to mark dirty, but -- as these attacks show -- this can expose vulnerabilities.
tzs 9y ago
Too bad segmentation was dropped for 64-bit code on x86, leaving just page tables. 32-bit x86 retains the segmentation model of the 286, extending it to 32 bits, and making it work with virtual addresses instead of physical addresses if the paging system is also enabled. Most 32-bit operating systems ignored the segmentation system, basically just running everything in what the old timers would call "small model". If we had segmentation in 64-bit mode, then I wonder if we could defend against a lot of these problems by running things we want to sandbox, such as JavaScript, in a different segment that only has access to the upper end of our virtual address space? As long as the sandboxed code cannot change the segment registers, this would prevent it from generating an address outside the sandboxed portion of the processes' virtual address space. I don't recall if the x86 segment system provides a way to trap attempts to change a segment register. If I recall correctly, it does support more than just the two level kernel/user protection system, and I think it supports not allowing loading a segment register with a selector that refers to a segment belonging to a higher level, so maybe if user mode was split into two levels, so sandboxed code could be run at a less privileged level than the main process it could work. In general, I think processor designers need to take into account the need for processes to run sandboxed code, and provide some kind of mechanism the processes can use to protect themselves from malicious code in the sandbox.
- sitkack 9y ago
  https://www.reddit.com/r/programming/comments/bkos1/what_has_happened_to_the_segment_registers_google/ https://www.reddit.com/r/programming/comments/bkos1/what_has... https://pdos.csail.mit.edu/~baford/vm/ https://pdos.csail.mit.edu/~baford/vm/
krylon 9y ago
> This means that all sorts of sandboxing methods for javascript interpreters, bytecode interpreters, plugin architectures, etc are insecure. I just now understood the impact of Spectre. It is not just that all existing attempts to execute code in a sandbox are vulnerable. For CPUs with this problem, it is literally impossible to create a secure sandbox. We certainly live in interesting times...
- zzzcpan 9y ago
  I'm still wrapping my head around Spectre. To me it does seem possible to create a sandbox secure against Spectre, but you have to recompile every program with retpoline to mitigate variant 2 and run in a separate process to mitigate variant 1. This way even if something breaks in a sandbox it will be able to see something else only from similar broken sandboxes, but not from other programs. Although there is a possibility of other side channel attacks. (hoping for someone to correct me if I'm wrong)

zackmorris 9y ago

Thank you, that was a succinct explanation of the difference between AMD/Intel and the order of speculation and protected memory access check for the Meltdown attack, and makes it easier to understand: https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability) https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili... I see now why the Spectre attack is so serious (reading out of bounds within the same process memory). I feel like there may be ways to catch unallocated memory access similarly to how protected memory works. But, that wouldn't help reads from allocated memory in runtime environments like for Javascript (where separate scripts in the same process space aren't meant to see each other's data). This is clearer to me now: https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit... Going forward, we may have to assume that security is only possible with true process isolation. For example this might put pressure on OSs to fix their slow context switching implementations to encourage the use of processes instead of threads. Beyond that, I can't see any easy way to fix the situation and am highly skeptical of things like compiler fixes, because there will likely always be another way to abuse various instructions to read outside memory boundaries.

tathougies 9y ago
The slow context switching between processes has nothing to do with OS implementation. True context switching involves a page table flush. This is slow due to caching, independent of the OS. The only thing the OS can do is tell the processor which parts not to mark dirty, but -- as these attacks show -- this can expose vulnerabilities.

tzs 9y ago

Too bad segmentation was dropped for 64-bit code on x86, leaving just page tables. 32-bit x86 retains the segmentation model of the 286, extending it to 32 bits, and making it work with virtual addresses instead of physical addresses if the paging system is also enabled. Most 32-bit operating systems ignored the segmentation system, basically just running everything in what the old timers would call "small model". If we had segmentation in 64-bit mode, then I wonder if we could defend against a lot of these problems by running things we want to sandbox, such as JavaScript, in a different segment that only has access to the upper end of our virtual address space? As long as the sandboxed code cannot change the segment registers, this would prevent it from generating an address outside the sandboxed portion of the processes' virtual address space. I don't recall if the x86 segment system provides a way to trap attempts to change a segment register. If I recall correctly, it does support more than just the two level kernel/user protection system, and I think it supports not allowing loading a segment register with a selector that refers to a segment belonging to a higher level, so maybe if user mode was split into two levels, so sandboxed code could be run at a less privileged level than the main process it could work. In general, I think processor designers need to take into account the need for processes to run sandboxed code, and provide some kind of mechanism the processes can use to protect themselves from malicious code in the sandbox.

sitkack 9y ago
https://www.reddit.com/r/programming/comments/bkos1/what_has_happened_to_the_segment_registers_google/ https://www.reddit.com/r/programming/comments/bkos1/what_has... https://pdos.csail.mit.edu/~baford/vm/ https://pdos.csail.mit.edu/~baford/vm/

krylon 9y ago

> This means that all sorts of sandboxing methods for javascript interpreters, bytecode interpreters, plugin architectures, etc are insecure. I just now understood the impact of Spectre. It is not just that all existing attempts to execute code in a sandbox are vulnerable. For CPUs with this problem, it is literally impossible to create a secure sandbox. We certainly live in interesting times...

zzzcpan 9y ago
I'm still wrapping my head around Spectre. To me it does seem possible to create a sandbox secure against Spectre, but you have to recompile every program with retpoline to mitigate variant 2 and run in a separate process to mitigate variant 1. This way even if something breaks in a sandbox it will be able to see something else only from similar broken sandboxes, but not from other programs. Although there is a possibility of other side channel attacks. (hoping for someone to correct me if I'm wrong)