If I understand this correctly, SVA is sort of a new instruction set architecture, which includes additional type information that allows them to make stronger safety guarantees? That’s rather interesting, although it sounds as though there might be some work involved in porting applications to this new architecture.
It’s sort of like taking the existing body of C and C++ code, and making that software behave more like a managed language such as C# or Java would. Keep the manual memory control, but gain a bunch of memory-isolation safety features.
It took me a few times reading it to really get what they were doing. The instruction set is just a modification of LLVM’s bytecode. The source language is C that gets compiled to LLVM bytecode like it always does. Their SAFEcode system just transforms that to make it safe from many attacks enforcing these properties: control-flow integrity, type safety for some things, array bounds safety, no uninitialized pointer dereferences, no double/illegal frees, and sound analysis for other compiler stuff. On top of that, they add virtual instructions to safely handle privileged operations like page tables, interrupt handling, and processor state manipulation. This requires changing allocators in source and maybe occasional other changes to facilitate analysis.
The Linux kernel port is a nice test of the system. They replaced architecture-dependent code, mostly assembly, with calls to SVA-OS instructions. The architecture-indepenent code modified was a total of 4,778Loc. That’s all it took to port the Linux kernel. I’m guessing average app or smaller OS would be easier. Performance impact was acceptable to me but significant. It ranged from 8% in file bandwidth to about 34% throughput hit for thttpd server to 67% for pipes. They came up with improvements and continue to work on it. A later one had almost no overhead on a few applications:
I’d be curious to hear what the C or kernel hackers think of their work. It’s unlike most of them. They combine interfaces to privileged operations to reduce risk of misuse, compiler transformations for safety, control-flow checks, and typed bytecode for more analysis. The 2007 version provided a lot of protection for Linux with minimal modifications. You can see their other work in Publications section of link at top of their Github. They describe SVA, SAFEcode, and others in plenty of detail.
If I understand this correctly, SVA is sort of a new instruction set architecture, which includes additional type information that allows them to make stronger safety guarantees? That’s rather interesting, although it sounds as though there might be some work involved in porting applications to this new architecture.
It’s sort of like taking the existing body of C and C++ code, and making that software behave more like a managed language such as C# or Java would. Keep the manual memory control, but gain a bunch of memory-isolation safety features.
It took me a few times reading it to really get what they were doing. The instruction set is just a modification of LLVM’s bytecode. The source language is C that gets compiled to LLVM bytecode like it always does. Their SAFEcode system just transforms that to make it safe from many attacks enforcing these properties: control-flow integrity, type safety for some things, array bounds safety, no uninitialized pointer dereferences, no double/illegal frees, and sound analysis for other compiler stuff. On top of that, they add virtual instructions to safely handle privileged operations like page tables, interrupt handling, and processor state manipulation. This requires changing allocators in source and maybe occasional other changes to facilitate analysis.
The Linux kernel port is a nice test of the system. They replaced architecture-dependent code, mostly assembly, with calls to SVA-OS instructions. The architecture-indepenent code modified was a total of 4,778Loc. That’s all it took to port the Linux kernel. I’m guessing average app or smaller OS would be easier. Performance impact was acceptable to me but significant. It ranged from 8% in file bandwidth to about 34% throughput hit for thttpd server to 67% for pipes. They came up with improvements and continue to work on it. A later one had almost no overhead on a few applications:
http://llvm.org/pubs/2009-08-12-UsenixSecurity-SafeSVAOS.pdf
Github of their current project which targets FreeBSD:
https://github.com/jtcriswell/SVA
I’d be curious to hear what the C or kernel hackers think of their work. It’s unlike most of them. They combine interfaces to privileged operations to reduce risk of misuse, compiler transformations for safety, control-flow checks, and typed bytecode for more analysis. The 2007 version provided a lot of protection for Linux with minimal modifications. You can see their other work in Publications section of link at top of their Github. They describe SVA, SAFEcode, and others in plenty of detail.
[Comment removed by author]