Slashdot Mirror
SRI/Cambridge Opens CHERI Secure Processor Design
An anonymous reader writes with some exciting news from the world of processor design: Robert Watson at Cambridge (author of Capsicum) has written a blog post on SRI/Cambridge's recent open sourcing of the hardware and software for the DARPA-sponsored CHERI processor — including laser cutting directions for an FPGA-based tablet! Described in their paper The CHERI Capability Model: Reducing Risk in an age of RISC, CHERI is a 64-bit RISC processor able to boot and run FreeBSD and open-source applications, but has a Clang/LLVM-managed fine-grained, capability-based memory protection model within each UNIX process. Drawing on ideas from Capsicum, they also support fine-grained in-process sandboxing using capabilities. The conference talk was presented on a CHERI tablet running CheriBSD, with a video of the talk by student Jonathan Woodruff (slides).
Although based on the 64-bit MIPS ISA, the authors suggest that it would also be usable with other RISC ISAs such as RISC-V and ARMv8. The paper compares the approach with several other research approaches and Intel's forthcoming Memory Protection eXtensions (MPX) with favorable performance and stronger protection properties. The processor "source code" (written in Bluespec Verilog) is available under a variant of the Apache license (modified for application to hardware). Update: 07/16 20:53 GMT by U L : If you have any questions about the project, regular Slashdot contributor TheRaven64 is one of the authors of the paper, and is answering questions.
Although based on the 64-bit MIPS ISA, the authors suggest that it would also be usable with other RISC ISAs such as RISC-V and ARMv8. The paper compares the approach with several other research approaches and Intel's forthcoming Memory Protection eXtensions (MPX) with favorable performance and stronger protection properties. The processor "source code" (written in Bluespec Verilog) is available under a variant of the Apache license (modified for application to hardware). Update: 07/16 20:53 GMT by U L : If you have any questions about the project, regular Slashdot contributor TheRaven64 is one of the authors of the paper, and is answering questions.
Complexity is bad for security.
Breathless excitement!
The achievements in the rest of this paper far outweigh the existence of a tablet built on this foundation.
They've created their own 64-bit processor! They've implemented a compiler for it! They've ported FreeBSD to it! That's some seriously impressive stuff!
But the leader has to be the laser cut tablet assembly. :-(
>CHERI processor
Really? Cheri?
http://cheri.com/ You have been promoted!
NOT SAFE FOR WORK.
--
BMO
I'm one of the authors of the paper (I did the LLVM support, some of the ISA design and the hardware implementation, and a token amount of OS work), so I'm happy to answer questions about it.
I am TheRaven on Soylent News
A processor is a piece of hardware, correct?
TFS says the Verilog source code of the processor is available. "Source code" sounds like software. I bet you can even run that source code on a general purpose CPU, can't you?
So is the processor hardware, software, or are the people who scream about "software patents" utterly clueless about computer engineering?
In theory, you could also take the verilog and generate a custom chip. In practice, you wouldn't want to without some tweaking. For example, our TLB design is based on the assumption that TCAMs are very expensive but RAM is very cheap. This is true in an FPGA, but is completely untrue if you were fabbing a custom chip.
Although we use the term 'source code', it's perhaps better to think of it as the code for a program that produces a design of a processor, rather than the source code for a processor.
In terms of software patents, there's some annoying precedent that a software implementation of a architectural patent can be infringing. The MIPS architecture that we implement has LWR and LWL instructions that accelerate unaligned loads and stores. These were patented (the patents have now expired) and the owners of the patent won against someone who created a MIPS implementation where these two instructions caused illegal instruction traps and were emulated in software. The software implementations were found to infringe the hardware patent.
I am TheRaven on Soylent News
The 'source code' we are talking about is not running on a processor. ;)
It is written in a HDL, a 'hardware description language'. The compiler is generating a chip layout which is then burned into an FPGA, a 'field programmable gate array' (or was it 'free'?)
So they use a 'programming language' to describe the logic, the circuits, of the processor.
The final result ofc is hardware that is capable of running FreeBSD and user land applications.
Hope that helped
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
There's a little bit of comparison to the Burroughs architecture that was one of the forerunners of the Unisys architecture in the paper. I'm not overfly familiar with the later Unisys MCP, so this may be wrong:
Our approach was explicitly intended to work with language that are not memory safe (i.e. C and friends). If you have a memory-safe language, then there is some cost associated with enforcing the memory safety in software, which CHERI can assist with, but you don't see much of a win.
As soon as you start mixing languages, you get the worst of all worlds. A typical Android application is written in C and Java (and some other things) and so gets all of the memory safety of C, plus all of the performance of Java. A single pointer error in the C code can corrupt the Java heap. One of my students last year implemented a modified JNI on CHERI that allows this sort of mixing but without the disadvantages. Java references are passed to C code as sealed capabilities, so the C code can pass them back to the JVM, but can't dereference them. The C code itself runs in a sandbox (C0 - the capability register that identifies the region of memory that normal MIPS loads and stores can use - is restricted to a smallish subset of the total [virtual] address space) so any pointer errors inside the C are constrained to only touch the C heap (of that particular sandbox - there can be a lot). He demonstrated running buggy and known-exploitable code in the JNI, without it compromising the Java code, with a very small overhead for calling in and out of the sandbox. Most interestingly, he was also able to enforce the Java security model for native code: the sandboxed code couldn't make system calls directly and had to call back into the currently active Java security monitor to determine whether it was allowed to.
Another of my students implemented an accurate (copying, generational) garbage collector for capabilities. This can be used with C code, as long as the allocator is outside of the normal C0-defined address space (otherwise pointers can leak as integers into other variables and be reconstructed). In particular, you can use this to track references to high-level language objects as they flow around C code and either invalidate them or treat them as GC roots, so you don't get dangling pointer errors. Or you can just use his allocator in C and have fully GC'd C code...
My understanding of MCP is that it uses high-level languages in the kernel, but does nothing to protect (for example) typesafe ALGOL code from buggy C code within the same userspace process.
I am TheRaven on Soylent News
Currently, Ohloh.net is aware of around 11 billion lines of C/C++ code. I'm including C++ because, while it's possible to write memory-safe C++, all of the evil pointer tricks that are permitted in C are also allowed in C++. Rewriting 11 billion lines of code, even in a language that is 100 times more expressive than C, would be a daunting task. Note that Ohloh only tracks open source code in public repositories: there's a lot more that's in private codebases.
For a fully memory-safe language, you need things like bounds checks on array accesses. Some research from IBM about 10 years ago showed that, with JVMs of the time, the cost of bounds checks accounted for the vast majority of the difference in performance between C++ and Java implementations of the same algorithms. They did some nice work on abstractions that allowed most bounds checks to be statically elided, but their approach never made it into the language. The overhead is somewhat hidden by superscalar architectures (the bounds check is done in parallel and the branch is predicted not-taken), but not on low-power in-order chips like the Cortex A7 that you'll find in a lot of modern mobile phones.
I am TheRaven on Soylent News
I appreciate your comments, but would like to add that it appears to me that correctness+security has by now become more important for applied computer science than processing throughput.
Yes, that's one of the motivations for our work. Now seems to be the time when it's possible to persuade CPU vendors that dedicating a little bit more hardware to security is valuable. It isn't quite the dichotomy that you describe though, because you can either implement security features in software or hardware and doing so in hardware can mean that you see a performance improvement for the sorts of use cases that people increasingly care about.
I am TheRaven on Soylent News
When old enemies arrive at your door bearing a gift horse large enough to fit a fireteam, don't stop at it's mouth, do a full cavity search.
Are there independent third-party audits underway? If DARPA likes it, I'm suspicious.
Multi-Pointer X, also called MPX
I have one of those in my home-router: a Lexra LX4189. It's a real shame though, such legal shenanigans didn't help the MIPS ISA overall.
Coming late to this party, I can only share this one datapoint: If I recollect right, it was the hardware on the Burroughs Large Systems that was memory-safe. Arrays were done as Segment Descriptors, and if you indexed outside the segment it raised an exception. Byte-addressed (for 6-bit, 8-bit, etc bytes) were done as "String Descriptors" that referred to the Segment Descriptor.
The only other hardware I know of that did this lately was the UCSB P-system; there may be others since then.
Yup. Compiling for the Burroughs architecture was easier than many segment-based systems, because they allowed segment descriptors to be placed in main memory, with the CPU responsible for tracking the value type by updating a tag. We adapt this slightly so that we only require one tag bit per 256 bits of main memory (the paper describes the implementation of this in some detail, but I'm happy to answer questions) to be able to safely store capabilities in main memory. Our design also allows normal C data structures to work as expected. You can mix C code compiled for MIPS and C code compiled for CHERI in the same binary (though you only get coarse-grained protection in the MIPS code).
The Burroughs architecture had very little impact on the computer architecture community, but was enormously influential in the design of VMs for high-level languages. One of our goals is to pull out the aspects of such VMs that are required for memory protection and put them back in the hardware, so a buggy VM has a far more limited security impact. My student's work on JNI dramatically reduced the amount of C code in the trusted computing base for the JVM implementation that he used.
I am TheRaven on Soylent News