1. 22

  2. 4

    I am very enthusiastic for CHERI, basically for the same reason I was enthusiastic for Rust. Memory unsafety is the enemy, I mostly don’t care whether it is solved in language or in hardware.

    1. 4

      CHERI doesn’t prevent programs from messing up their memory, it only prevents the mess from being exploitable. Anything that a language can catch at compile time is better, because it prevents buggy code from existing, rather than merely making it crash faster.

      1. 7

        It’s worth noting that CHERI and Rust are not mutually exclusive. There was a talk at CHERITech22 yesterday about using Rust with CHERI. CHERI protects the unsafe blocks of Rust code as well as the safe ones. It also protects all of the C/C++/assembly code that you reuse in your shiny new Rust program.

        I’m very much in favour of safe languages but they should be primarily giving you availability guarantees, not confidentiality or integrity: the hardware should ensure that your memory-safety bugs can’t leak or corrupt data. A safe language should ensure that you can’t, by construction, introduce these bugs. In fact, I wrote a section of the blog post (and gave a talk on this subject at the DSbD Roadshow back in March) on exactly this topic.

        1. 2

          Yes, but if memory bugs were unexploitable it would substantially change the tradeoff for me (and I imagine many others). I certainly wouldn’t evangelize Rust around.

          1. 2

            Aren’t you underwhelmed that CHERI’s solution is merely a crash, rather than improvement in program’s stability? What about data-race-free multi-threading that Rust can help with, but CHERI can’t (other than again crashing faster)?

            I’m so happy that Valgrind and ASAN aren’t in my toolbox any more. I don’t even chase null pointer crashes.

            1. 1

              That’s great if you’re in a place where you have no dependencies on any C/C++/assembly libraries and can write clean-slate code in Rust (with no use of unsafe) for everything that runs in the same address space as your code. For everything else, there’s CHERI.

          2. 2

            How can it prevent it from being exploitable if I can still make a program change my state from “unauthorized” to “admin” by overwriting a suitable byte in memory using eg malformed input or some such?

            1. 3

              CHERI gives you per-object (and, with the right compiler flags, if your code works in this mode) per sub-object (structure field or array element) bounds protection. If you are reading into a buffer from the network, CHERI prevents the kind of bug that you’re proposing in a few ways:

              • If unauthorised and admin are pointers to user structures, then CHERI completely prevents it because it prevents pointer injection. Pointers follow a strict provenance model and so every valid pointer must be derived from another valid pointer (starting, in userspace, from the ones that the kernel gives you either on process startup or in response to mmap or similar system calls).
              • CHERI gives you tight bounds enforcement. If you are using sub-object bounds and you pass a pointer to a struct field to the read / recv system call, then the compiler will restrict the bounds to that field. If the attacker tricks you into reading too much data so that it would overwrite the state stored in the next field, you’ll get a trap.

              Of course, if you parse a message from the network and have a logic bug, then nothing short of formal verification will catch it.

              1. 2

                CHERI isn’t meant to prevent all bugs in the program. It’s only able to crash the program when detecting specific types bugs associated with faulty manual memory management and pointer arithmetic.

                It can’t prevent higher-level logic bugs that don’t happen to access memory outside of their CHERI-protected area, but that’s a given with such solutions. There isn’t any single one yet that can prevent all bugs, but that doesn’t mean we shouldn’t be eliminating bugs we can.

                1. 3

                  It’s only able to crash the program when detecting specific types bugs associated with faulty manual memory management and pointer arithmetic

                  More specifically: The hardware will generate an abort when you have this kind of bug. It’s then up to your software stack what you do with it. On CheriBSD, it generates a SIGPROT, which you can choose to handle and will crash the program only if you don’t. At the very least, you can use the SIGPROT to generate stack traces and other telemetry that will let you fix the bug.

                  Unlike a SIGSEGV, you are guaranteed to get the SIGPROT before the out-of-bounds access that cause memory corruption and so you might still be able to recover: the program is likely still in a well-defined state, whereas a SIGSEGV generally happens only after you’ve clobbered some other objects.

          3. 1

            I wonder if this version of CHERI would also be easier to build some hardware for so that more people could try it out? This sort of hardware would fit fine on an older node, like the Skywater 130 nm node, for which the PDK is open, and there are shuttles for it, which bring the cost down even more. OpenMPW could be used, but even the paid efabless shuttles aren’t out of the question, as 20$/chip, even if a bit much, isn’t that much of an ask for a new architecture development platform.

            1. 3

              It should be fine, yes. It’s very small. If you put it in a system with 512 KiB of SRAM then it’s a tiny bit over in the corner. I’m particularly interested in companies that make absolutely dirt-cheap SoCs for IoT adopting this. We can give them a safe way of having a network-connected device where compromising the network stack can’t compromise the rest of the system.

              1. 1

                Hmm, at that size, I might see it being used as the “dark” cores in the silicon, which are dedicated for one specific task only. E.g. M1 has over 30 of such cores, and security is often fairly important for such cores. For dirt-cheap SoCs, it might be too weak, since usually they run at least part of WiFi stack on the cores. But with more abilities, I could see that.

                1. 3

                  Yes, that’s definitely one of the use cases we have in mind.