9 ms·
Arm releases experimental CHERI-enabled Morello board
- magicalhippo 5y agoPrevious related submission, with a nice context comment: https://news.ycombinator.com/item?id=29951145 https://news.ycombinator.com/item?id=29951145
- plutonorm 5y agoI wager it will be hacked in under a year.
- jrtc27 5y agoNobody's claiming it's "hack-proof", that would be foolish, just that it removes certain classes of vulnerabilities that are the majority of CVEs for code written in memory-unsafe languages, thereby reducing the attack surface. Independent analysis by both Microsoft and Google has shown that's around 70% of vulnerabilities, which still leaves around 30%, but is a big step forward.
- lacksconfidence 5y agoNot OP, but that's not how I interpreted their comment. I interepreted it as the 70% they hope to have fixed will end up having edge cases not yet considered, and the protections will end up weaker than desired. No-one designed a processor to be susceptable to spectre and meltdown, once something moves into production there is significantly more incentive to investigate and find these flaws.
- cosmiccatnap 5y ago
- pjmlp 5y agoThere are no CVEs related to Solaris SPARC Application Data Integrity, or Unisys ClearPath MCP. Either they aren't interesting for hackers, or they actually did a good job with hardware memory tagging.
- jrtc27 5y agoWe do have formal proofs of various security properties at the architectural level that consider the entire architecture with all its complexities and warts. Speculative execution is of course a concern (and is an active area of research for us), though our belief is that the bounds information now present at the hardware level allows it to be tamed. Another concern is the interaction between undefined behaviour and CHERI; the former needs to be sufficiently constrained in order to not inadvertently turn code that would be memory safe with a naive CHERI compiler into code that is not. We also know there are still memory safety-like issues we can't protect against; we can stop pointer injection, but we can't stop tricking programs into copying the "wrong" pointer somewhere, or type confusion bugs that result in using pointers in an unintended way. Many of those exploit chains today rely on exploiting some other memory safety vulnerability we do protect against, but we cannot predict if people will come up with alternative approaches that avoid those in a world with CHERI.
- lacksconfidence 5y agoThank you. Your response's here and throughout this thread have been quite enlightening.
- plutonorm 5y agoExactly - these formal methods have implicit assumptions in them. Within their axioms/priors they are proven correct. But the devil is in those assumptions. And that is disregarding the rather foggy notion of 'proof'. Is this proof written in a formal proof system that automates the proof? Because if it isn't you have another source of error. Even if it is in a formal proof system, who is to say that there is no error in the formal proof system? I admit that each layer adds more assurance - but appealing to 'formal proof' is a bit like appealing to god, it's an appeal to an unassailable authority. When in fact, once you know the details these things are never so clear cut.
- gchadwick 5y agoWhat exactly do you mean by hacked? This isn't a product with some singular security aim, it's an evaluation platform that's come from an ongoing large research project. Previous work (using FPGA and software simulation) will have found and fixed many architectural issues. No doubt more will be found here. In a sense the entire aim of this is for it to be 'hacked' to further improve the security architecture.
- thrwyoilarticle 5y agoDo you have criticisms of the feature or is this facile cynicism?
- DrBazza 5y ago> The CHERI memory-protection features allow historically memory-unsafe programming languages such as C and C++ to be adapted to provide strong, compatible, and efficient protection against many currently widely exploited vulnerabilities. https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
- bluejekyll 5y agoMy reading of that linked article on CHERI is two things. First that software needs to adopt the instructions in order to use it. It then raises a question of what is the benefit. What is the experience compared to today, and it should be that embedded software can gain some of the features that are generally reserved for user space. That’s virtual memory protection. The experience then I would guess is that software will crash rather than, for example, read bad data from the wrong address space. A feature user space apps get from virtual memory (if it’s outside their processes memory space that is). Did I get this right? Also, it should help Rust just as much, especially in unsafe code regions.
- jrtc27 5y agoSoftware doesn't need to "adopt the instructions", it just needs to be recompiled in the same way as you compile it for a new architecture (CHERI is effectively like the 32-to-64-bit transition in that sense). Yes, having capabilities allows you to bring memory protection to the MMU-less embedded space (see for example the now somewhat old paper https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201810-iccd2018-cheri-rtos.pdf https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201810...). Yes, if you attempt to access outside the bounds of a capability you will deterministically crash. This is true even if you do have virtual memory and there is memory there. Yes, the use of CHERI to protect unsafe code in memory-safe languages like Rust is of interest to us. There is also the possibility of being able to remove some of the compiler-generated bounds checks by using the capability bounds instead, though some care is needed to preserve the precise semantics (but some may also be happy to slightly change the semantics if it means they can all be removed and potentially improve performance).
- fulafel 5y agoHow does it compare to previous proposed hw assisted ways to bolt memory safety onto C? Like Hardbound, In-Fat, MPX for example.
- mwcampbell 5y agoI'll leave it to others to go into technical details, but the most obvious answer is that this effort has major industry players behind it, meaning it might actually make it into production.
- pjmlp 5y agoAs mentioned in another reply, there are already a couple of tagging approaches in production. Unfortunely x86/x64 don't have any, and MPX was broken from the get go.
- aseipp 5y agoThis isn't a memory tagging system at all and has capabilities far beyond that (pun intended), so I don't know why whatever other approaches like MTE are out in the wild are relevant.
- jrtc27 5y agoThey're relevant because they're technologies relating to memory safety and provide some level of additional protection. However, they rely on secrets and are in general only probabilistic, so they don't deterministically mitigate all memory safety issues (you can deterministically mitigate some with clever allocations of memory "colours", but not all). CHERI and MTE-like schemes also both rely on the use of tagged memory, but in rather different ways.
- pjmlp 5y agoThey are 100% relevant in what concerns taming the native code produced by C derived languages.
- 5y ago
- jacquesm 5y agoIt would be nice to see a side-by-side Linux port to log the number of issues that the Morello board caught for a system that runs some software that is actually in production.
- phkahler 5y agoOr test software that has known vulnerabilities and see if it actually prevents them.
- pm215 5y agoThe "Linux enablement" section of https://www.morello-project.org/ https://www.morello-project.org/ says that is "under development", with an initial prototype musl based system available now and a fuller-fat Debian scheduled some time this year.
- jrtc27 5y agoOur work is based on FreeBSD as its tight integration makes it much easier to manage forking in a research setting, compared with the umpteen different repositories you need to fork and keep in sync to build a Linux distribution. Arm have a minimal Android stack and are working on a Linux distribution (but their current Linux kernel implementation does not enforce capability protection, it's done by a userspace wrapper, and only a select number of binaries in the Android image are pure-capability, many are still plain AArch64), initially based on musl, but it's still a long way behind where we are on FreeBSD where we have (almost) all of the userspace and kernel ported as pure-capability code (the "almost" is because we have not yet invested the engineering effort in porting DTrace and ZFS, but both are on our roadmap as they're important for real use).
- jacquesm 5y agoInteresting. But: given the amount of server side software that is running on Linux I think a FreeBSD port, while useful is not going to see the kind of adoption that a Linux port would, it will serve as a useful POC but ultimately the challenge will be to get this into the mass market and there it will not really help.
- netr0ute 5y agoWhat about RISC-V?
- jrtc27 5y agoWe also have a CHERI-RISC-V specification (https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-951.pdf https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-951.pdf), with support in CHERI LLVM, CHERI QEMU and CheriBSD, plus three open-source FPGA implementations (https://github.com/CTSRD-CHERI/Piccolo https://github.com/CTSRD-CHERI/Piccolo, https://github.com/CTSRD-CHERI/Flute https://github.com/CTSRD-CHERI/Flute, https://github.com/CTSRD-CHERI/Toooba https://github.com/CTSRD-CHERI/Toooba) that span various parts of the microarchitecture design space, and it is the platform we use for our own research on architecture and microarchitecture. But for various reasons (e.g. proximity to the university, existence of competitive microarchitectures several years ago, ISA and ecosystem maturity, enthusiasm and interest on their part) Arm was the right partner for this program.
- netr0ute 5y agoThen the HN title is inaccurate.
- klelatti 5y agoAre you saying Arm haven't released a CHERI enabled Morello board?
- netr0ute 5y agoIt's technically true, but it makes it look like CHERI is only for ARM.
- jrtc27 5y agoI don't see why it implies that. "Arm releases experimental DDR5-enabled $NAME board" wouldn't make it sound like DDR5 is only for Arm, so why would "Arm releases experimental CHERI-enabled Morello board"?
- phkahler 5y agoHow does this compare to testing with address sanitizers?
- andsanmar 5y agoSimple, testing won't prevent you from all the bugs bun only the ones you run over when testing (either fuzzing or unit testing). While enforcing some safety semantics like they do here through capabilities, does. This means, at least for using CHERI you have to go through a custom compilation stack, the CHERI team has already been working on this tooling for long.
- trasz 5y agoApart from some more interesting scenarios enabled by CHERI: you probably don’t want to run all your production software with address sanitizers, because it would be unacceptably slow. Here the performance overhead is negligible.
- phkahler 5y agoBut maybe we can run sanitizers during testing and catch most of the issues CHERI will find without building it into hardware. OTOH that doesn't do anything to protect against malicious code, but that should be properly sandboxed anyway.
- jrtc27 5y agoYou should indeed run sanitisers during testing and catch most of the issues; we encourage this! What CHERI provides is twofold: 1. Memory safety issues not found in testing do not lurk as exploitable vulnerabilities; testing is never perfect, often far from it when it comes to edge/unexpected cases where vulnerabilities lurk (though fuzzing can help somewhat) 2. Sandboxing still needs some kind of isolation primitive, which CHERI can provide in place of the heavyweight MMU-based techniques that exist today Plus let's not kid ourselves that all software is being tested with sanitisers. The vast majority of software running on your system probably is not.
- 5y ago
- mwcampbell 5y agoI wonder how hard it will be to retrofit CHERI support into Windows, macOS, and Chromium, so we can have a new defense against browser sandbox escapes, making remote browser isolation products irrelevant.
- jrtc27 5y agoWindows is likely a big task for the same reasons as SMAP (https://github.com/microsoft/MSRC-Security-Research/blob/master/papers/2020/Evaluating%20the%20feasibility%20of%20enabling%20SMAP%20for%20the%20Windows%20kernel.pdf https://github.com/microsoft/MSRC-Security-Research/blob/mas...). XNU should be comparable to FreeBSD, which CheriBSD is a fork of, as both use Mach's VM for memory management and have a bunch of shared code in various places, but userspace is more of an unknown quite how much effort it'd be (you'll need to port Objective-C and, now, Swift, for example). For Chromium we have ported WebKit, so I'd imagine Blink isn't too dissimilar. V8 is likely interesting, though we have a version of WebKit's JSC JIT for Morello, which gives confidence in V8 being doable.
- pjmlp 5y agoThat is already slowly happening on the versions that have access to ARM hardware memory tagging and pointher authentication, specially on iOS and Android. Solaris on SPARC has about one decade of experience via Application Data Integrity. And Unisys ClearPath MCP memory tagging architecture goes back to its Burroughs B5500 roots. Also in case you missed it, Microsoft is one of the CHERI sponsors.
- stan_g 5y agoWith funding of DARPA how sure can we be that it will not have a backdoor? Is there a way to proof that there is no backdoor to the security features?
- _0w8t 5y agoI wonder if this is kind of return to segmented architecture? It so it seems flat address spaces backed by virtual memory where not so good idea to begin with.
- jrtc27 5y agoCHERI is orthogonal to virtual memory, and the two complement each other. You still want virtual memory so you can do the usual paging tricks, copy-on-write, sharing of read-only pages, and so on. Plus the fact that there is a single page table entry for an address that affects all accesses is crucial for our experimental temporal memory safety implementation (see https://msrc-blog.microsoft.com/2022/01/20/an_armful_of_cheris/ https://msrc-blog.microsoft.com/2022/01/20/an_armful_of_cher...). There's nothing stopping you from using segments instead of flat address spaces with page tables, but it's not really related to CHERI, you still have the same trade-offs as you do on conventional architectures.
- zeotroph 5y agoOn most current archs: > Any piece of code running in a process can construct an integer value and, if this integer corresponds to a valid location in the process’ address space, then it can access memory at that location. What this adds: > CHERI changes this. Every load or store instruction and every instruction fetch must be authorized by an architectural capability. So it should be possibly to call into any function (e.g. from an untrusted blob, and given the capabilities are set up) and on return have the guarantee that none of the callers memory has been touched and all the side effects are contained in the return value, and maybe selected whitelisted addresses? I remember the mill architecture[1] also claims to have that capability, I think they called these calls "Portals". Btw the talks by Ivan Godard are a must watch if you have any interest in hardware architecture. But how can existing code be just a recompile away from benefiting from these features, don't the capabilities have to be set up somehow (unless it is purely functional language)? 1: https://millcomputing.com/docs/ https://millcomputing.com/docs/
- jrtc27 5y agoThe C startup code (for statically-linked binaries) and run-time linker (for dynamically-linked binaries) carve up initial capabilities provided by the kernel into capabilities that cover the various global variables and function pointers needed by the program and libraries, similar to how pointers are initialised for position-independent code (more complex, but same principle, just scan through all the relocations and apply them). When you mmap(2) memory from the OS, you get back a capability with bounds covering that memory. When you malloc(3) memory from your libc, it finds space in an existing mapping, takes that capability and restricts its bounds to the allocation size. When you take a pointer to a stack-allocated variable, the compiler inserts an instruction to set the bounds of that capability to just the memory it allocated for that variable. Every pointer, whether "language-level" (what is exposed in the language) or "sub-language-level" (the pointers in the implementation, like return addresses on the stack or the stack pointer itself), is a capability, and all you need to do is insert a bounds-setting instruction at the point of allocation to restrict its bounds. So your libc's malloc needs modifying, as does your kernel, but your C program that calls them just needs to be recompiled for the pure-capability ABI. Edit: To answer the first question, yes, that is the primitive which enables CHERI to be used for in-address-space compartmentalisation rather than relying on an MMU for process-based separation and all the overheads that come from context switching address spaces.
- transpute 5y agoHopefully ARM's MTE (memory tagging extension) will appear in Apple's 2022 SoCs (M2, A16), https://security.googleblog.com/2019/08/adopting-arm-memory-tagging-extension.html https://security.googleblog.com/2019/08/adopting-arm-memory-... (2020) CheriBSD port to Morello, https://www.youtube.com/watch?v=7aVygpgkm1 https://www.youtube.com/watch?v=7aVygpgkm1 (2021) GCC support for Morello, https://gcc.gnu.org/pipermail/gcc/2021-July/236868.html https://gcc.gnu.org/pipermail/gcc/2021-July/236868.html (2021) OSS desktop software stack, https://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-cheri-desktop-report-version1-FINAL.pdf https://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-c... > We measure a 0.026% Lines-of-Code (LoC) change rate in approximately 6 million lines of C and C++ code to introduce CHERI memory safety. In our review of past vulnerabilities, we see likely mitigation rates of 91% for X11, 82% for Qt, 43% for KDE, and 100% for other supporting libraries (typically image processing). (2022) Microsoft Research, https://msrc-blog.microsoft.com/2022/01/20/an_armful_of_cheris/ https://msrc-blog.microsoft.com/2022/01/20/an_armful_of_cher... > We can implement this model on a variety of mechanisms, such as MMU-based isolation or software fault isolation, but expect that CHERI will provide better performance and scalability than anything on current commodity hardware ... If the Morello program can demonstrate that CHERI meets the performance goals for real-world use then it is a game changer for security, deterministically preventing spatial safety vulnerabilities and (with software support) heap temporal safety bugs, dramatically reducing the set of bugs that become exploitable as for anything other than denial of service.
- dilippkumar 5y agoIf I understand this correctly, we now get 128 bit pointers. The lower 64 bits are the address and the upper 64 bits are permissions. Did I miss anything?
- saagarjha 5y ago129 bits, there's a "valid" bit at the top. For most software this is invisible but some code will need to care (most notably, anything that copies pointers will need to preserve that bit.)
- titzer 5y agoIt's really great to see this level of hardware innovation and investment into security! Although it's a bit of a shame that we're down this path because of the inertia of unsafe programming languages and systems that put performance first. In some sense we're starting to pay back a big debt. I try to choose my words carefully (these kinds of conversations can get pretty toxic pretty quick). But honestly I think in the long arc of history, C will be regarded like asbestos: very obviously dangerous in retrospect. I respect the designers of C immensely and the amount of work many thousands of people the world over have put into that entire toolchain and ecosystem, but we can't blamelessly have that conversation yet, so I guess I'll stop here.
- pjmlp 5y agoThe year is 1961 and C is still about 10 years away to become a reality, https://en.wikipedia.org/wiki/Burroughs_large_systems_descriptors https://en.wikipedia.org/wiki/Burroughs_large_systems_descri...
- staticassertion 5y agoThis is extremely exciting to me. While at my company we use Rust almost exclusively there's still lots of peripheral software we rely on in C and C++. Getting spatial memory safety nearly "for free" in those projects will make me feel way, way better.
- musicale 5y agoThis is pretty interesting - even more so if we might see it in mainstream desktop and mobile ARM chips from the likes of Apple et al..
- ProfHewitt 5y agoGreat to see further progress on CHERI! See the following for theoretical foundations for the work: Linux 60th Anniversary Keynote https://t.co/IRe3vpMlWn https://t.co/IRe3vpMlWn
- jrtc27 5y agoYour research on actor-based programming models has nothing to do with C/C++ spatial and temporal memory safety.
- ProfHewitt 5y agoFoundation is about rigorously specifying the general Laws of Locality for Actor systems that CHERI implements.
- jrtc27 5y agoCHERI is not an actor system. It is a capability system aimed at memory protection. It can be used, like any other architecture, as a basis upon which to build an actor-based framework/system, but it is no more of an actor system than, say, x86. The concepts are deeply rooted in the capability system literature.
- ProfHewitt 5y agoActorsTheory serves as the rigorous mathematical foundations of capability systems.