3 ms·

Yeah, there's a ton of them in the literature. Anything enforcing memory safety (eg Softbound+CETS or SAFEcode), control-flow integrity (esp Code-Pointer Integr

Yeah, there's a ton of them in the literature. Anything enforcing memory safety (eg Softbound+CETS or SAFEcode), control-flow integrity (esp Code-Pointer Integrity w/ segments), data-flow integrity, information-flow control, etc might be useful to build on here. Many are designed for C, too, which is closer to metal than Javascript, has tons of automated checkers (eg RV-Match from RVI), and a certifying compiler (CompCert). The other drawback is you have less layers of protection if operating in process with language-based and/or tactical mitigations. The MMU can isolate what we call known unknowns where something goes wrong (eg bitflip or RAM decay on protection mechanism), the app goes rogue, and it's still contained a bit. That's why the strongest approach from high-assurance security is still separation kernels: microkernels designed specifically for security that fit into L1 caches, are often mathematically verified in some way, support individual apps running in own address space optionally on a language runtime, and support VM's for legacy apps. Muen is an example of that approach for x86, seL4 an example for ARM (mainly ARM), and INTEGRITY-178B a commercial example for PPC (beware marketing hype): https://muen.sk/ https://muen.sk/ https://sel4.systems/ https://sel4.systems/ https://www.ghs.com/products/safety_critical/integrity-do-178b.html https://www.ghs.com/products/safety_critical/integrity-do-17...

stcredzero 8y ago
The other drawback is you have less layers of protection if operating in process with language-based and/or tactical mitigations. Just because one abstracts-away the sandbox from the users doesn't mean that the sandbox can't be used as a layer of protection. The wiser approach would be to use an additional layer, though it's abstracted away from the user's point of view.
- nickpsecurity 8y ago
  I agree. Im just emphasizing it since many people think safe languages can be enough security because the forget attacks that break abstraction gaps. One benefit of Spectre/Meltdown and Rowhammer was helping me counter that more easily. :)

stcredzero 8y ago

The other drawback is you have less layers of protection if operating in process with language-based and/or tactical mitigations. Just because one abstracts-away the sandbox from the users doesn't mean that the sandbox can't be used as a layer of protection. The wiser approach would be to use an additional layer, though it's abstracted away from the user's point of view.

nickpsecurity 8y ago
I agree. Im just emphasizing it since many people think safe languages can be enough security because the forget attacks that break abstraction gaps. One benefit of Spectre/Meltdown and Rowhammer was helping me counter that more easily. :)