Forgot your password?
typodupeerror
Hardware Hacking Programming Hardware Build

SRI/Cambridge Opens CHERI Secure Processor Design 59

Posted by Unknown Lamer
from the dreaming-of-hurd/coyotos dept.
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.
This discussion has been archived. No new comments can be posted.

SRI/Cambridge Opens CHERI Secure Processor Design

Comments Filter:
  • Complexity is bad for security.

    • Agreed, the more complex something becomes, the more likely there is to be a blindspot or loophole in the design.
    • Re: (Score:3, Informative)

      by Anonymous Coward

      Capabilities are simpler than "simple" paged memory management. Every pointer carries permissions, enforced in hardware, instead of requiring several layers of software to perform their own ownership management.

      • Note that, in our implementation, capabilities are orthogonal to paged memory management. CHERI's capabilities are within a virtual address space. The MMU is a really useful abstraction for an OS wanting to isolate processes from each other and implement things like swapping, lazy allocation, and so on. It's a pretty poor abstraction for implementing memory safety and sandboxing within an application. We regard the two as complementary: CHERI provides both a traditional MIPS TLB and capabilities, and th
    • by Anonymous Coward

      Complexity is bad for security.

      To paraphrase Einstein, "security should be as simple as possible, but no simpler."

    • by Anonymous Coward

      Simplicity is an illusion we place on reality. In reality, simplicity is merely trading complexity for a predefined set of rules that only come about through even more complex ideas.

      This is exactly what they are doing. They are trading the complexity of 5 million different programmers trying to be secure for hardware designed by a few really smart people.

      In this case, things become simpler for everyone, including the hackers, as they only have to hack one model. However, since the compilers are in on it, th

    • by TheRaven64 (641858) on Wednesday July 16, 2014 @11:04AM (#47466749) Journal
      Yes, we agree. That's why we have a fairly simple set of instruction set extensions requiring no complex logic (TCAMs, associative structures, complex data structure walkers, and so on) that we have formally verified provide the required security properties.
  • by Gollum (35049) on Wednesday July 16, 2014 @09:31AM (#47465991)

    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. :-(

    • by TheRaven64 (641858) on Wednesday July 16, 2014 @11:02AM (#47466733) Journal
      To be fair to the submitter, Theo did some amazing work with the laser cutter to produce the tablets. Mine doesn't have the SRI and Cambridge logos etched into the front (or a battery, actually - it's one of the first models) but the it's still very nice. Not really competitive with the iPad, but definitely something we can plausibly use as a prototype.
  • 4chan comment (Score:2, Offtopic)

    by bmo (77928)

    >CHERI processor

    Really? Cheri?

    http://cheri.com/ [cheri.com] You have been promoted!

    NOT SAFE FOR WORK.

    --
    BMO

    • by bmo (77928)

      I know it's poor form to bitch about moderation, but "offtopic?" Really?

      It never crossed anyone's mind to type the name into a web browser? You know, just to make sure that it didn't link to something like lemonparty?

      --
      BMO

  • Any questions? (Score:5, Informative)

    by TheRaven64 (641858) on Wednesday July 16, 2014 @01:21PM (#47468085) Journal
    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.
    • 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?

      • by TheRaven64 (641858) on Wednesday July 16, 2014 @02:42PM (#47468895) Journal
        The processor is implemented as a softcore in BlueSpec SystemVerilog, which is a high-level hardware description language (HDL). The source code can be compiled to C for simulation, so you can run it on a general-purpose CPU. We get around 30K instructions per second doing this. It can also be compiled to verilog and then synthesized into gate layouts for an FPGA. We can run at 100MHz (probably 125MHz, but we don't push it) in an Altera Stratix IV FPGA, with around 1 instruction per clock (a bit less), so around 3000 times faster than simulation.

        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.

        • by goarilla (908067)

          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

      • 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 ;)

    • 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.
      • I hope no one misses the irony of using a DARPA-funded network protocol to post about how evil DARPA is...
        • by Garridan (597129)
          I didn't say that DARPA was evil. I just said that this merits an independent audit. I take your flippant answer for a "no".
          • The flippant answer is all that your paranoia deserves. The work was undertaken by SRI and The University of Cambridge. The funding was provided by DARPA, but that's the extent of their involvement (other than creating a program with the goal of being able to redesign any aspect of computing with security in mind).

            The code is no more or less meriting an independent audit than any other open source code. Less, actually, because we don't anticipate anyone actually using our open source reference impleme

            • by Garridan (597129)

              The flippant answer is all that your paranoia deserves.

              A healthy amount of paranoia is a must in the security industry. Every piece of security hardware or sofware demands third-party evaluation, even that made by people you trust completely. Not all flaws are deliberate. Thank you for your time, and (at last) thoughtful response.

    • Has anyone on the project thought about extending the design to include secure key storage? (I'm thinking specifically of something like TRESOR / TreVisor)
      • We haven't specifically looked at key storage, but we are looking at potential ways of extending the approach to heterogeneous multicore systems, so that access to main memory could be delegated to accelerators (at varying levels of coupling) via capabilities and capabilities could be used to mediate access to accelerators. In this scheme, it would be possible to provide an encryption coprocessor that would store keys internally and perform encryption and decryption operations on blocks of memory delegated

    • Is the code for the LLVM support publically available / do you have a link for it?

      • Yup, it's on GitHub in two repositories, one for LLVM [github.com] and one for clang [github.com]. We've been pushing the fixes for MIPS IV upstream, but there are some changes to the mid-level optimisers to make them aware that not all pointers are integers and some extensions to the platform-independent code generators for the same.

        We've upstreamed all of the FreeBSD changes required for the base processor (BERI) and the development boards, so FreeBSD 10 will run out of the box on CHERI (it just won't expose any of the capabil

  • Multi-Pointer X, also called MPX

You will lose an important disk file.

Working...