3 ms·

> And if you insert dynamic checks instead, you're talking about turning each memory access into many (memory accesses that in a modern CPU are hidden by the TL

by cesarb 9y ago

> And if you insert dynamic checks instead, you're talking about turning each memory access into many (memory accesses that in a modern CPU are hidden by the TLB). You only have to check that the memory address is not negative (kernel pointers are negative on x86-64). No extra memory access needed. > You can't do any sort of static analysis I'm aware of that'll still allow you to run C code (which let's you manufacture pointers from arbitrary integers). NaCl managed to do it (https://developer.chrome.com/native-client/reference/sandbox_internals/x86-64-sandbox https://developer.chrome.com/native-client/reference/sandbox...).

rayiner 9y ago
Good point about the ease of checking kernel pointers. That doesn't address process isolation generally, however, unless you're willing to segment virtual memory in the same way. As to NACL, it relies on various CPU protection mechanisms, and also makes some major trade-offs: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/35649.pdf https://static.googleusercontent.com/media/research.google.c.... On x86, NACL uses the segmentation mechanism. On x86-64, which has no segmentation registers, it masks addresses and requires all memory references to be in a 4GB space. To handle various edge cases, and to speed up stack references, it relies on huge guard areas on either side of the module heap and stack, thus relying on the virtual memory system. Finally, likely to mitigate the overhead of masking, it does not address reads at all, and relies on the virtual memory system to protect secret browser information from the sandboxed process. Even with these limitations, on about half the SPEC benchmarks the overhead is 15-45%.
api 9y ago
Good point about static analysis and C code. That means you would not be able to toss memory protection unless you introduce fast hardware support for bounds checking and bounds check everything in JITed code. I guess you could also have the JIT do more elaborate guarding of memory but that would probably have a performance penalty. You could still toss a lot: virtualization, complex multi-layered protection modes, address remapping, and essentially every hardware feature that exists to support legacy binary code. All deprecated instructions and execution modes could go, etc. Finally you would maintain the benefit of architecture flexibility. Switching from x86 to ARM, etc., would be easy.

by cesarb 9y ago

rayiner 9y ago

Good point about the ease of checking kernel pointers. That doesn't address process isolation generally, however, unless you're willing to segment virtual memory in the same way. As to NACL, it relies on various CPU protection mechanisms, and also makes some major trade-offs: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/35649.pdf https://static.googleusercontent.com/media/research.google.c.... On x86, NACL uses the segmentation mechanism. On x86-64, which has no segmentation registers, it masks addresses and requires all memory references to be in a 4GB space. To handle various edge cases, and to speed up stack references, it relies on huge guard areas on either side of the module heap and stack, thus relying on the virtual memory system. Finally, likely to mitigate the overhead of masking, it does not address reads at all, and relies on the virtual memory system to protect secret browser information from the sandboxed process. Even with these limitations, on about half the SPEC benchmarks the overhead is 15-45%.

api 9y ago

Good point about static analysis and C code. That means you would not be able to toss memory protection unless you introduce fast hardware support for bounds checking and bounds check everything in JITed code. I guess you could also have the JIT do more elaborate guarding of memory but that would probably have a performance penalty. You could still toss a lot: virtualization, complex multi-layered protection modes, address remapping, and essentially every hardware feature that exists to support legacy binary code. All deprecated instructions and execution modes could go, etc. Finally you would maintain the benefit of architecture flexibility. Switching from x86 to ARM, etc., would be easy.