Arm releases experimental CHERI-enabled Morello board

https://www.lightbluetouchpaper.org/2022/01/20/arm-releases-experimental-cheri-enabled-morello-board-as-part-of-187m-ukri-digital-security-by-design-programme/

by zxombie • 5 years ago

168 82 5 years ago

lightbluetouchpaper.org

magicalhippo• 5 years ago

Previous related submission, with a nice context comment:

https://news.ycombinator.com/item?id=29951145

plutonorm2• 5 years ago

I wager it will be hacked in under a year.

jrtc2721• 5 years ago

Nobody'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.

lacksconfidence2• 5 years ago

Not 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.

gchadwick• 5 years ago

What 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• 5 years ago

Do you have criticisms of the feature or is this facile cynicism?

DrBazza• 5 years 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/

bluejekyll2• 5 years ago

My 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.

jrtc2721• 5 years ago

Software 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...).

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).

_0w8t2• 5 years ago

With a program split into multiple small compartments one does not need to crash the whole application on out-of-bound access. It will be enough to signal the parent compartment that one of its children performed an illegal operation.

fulafel2• 5 years ago

How does it compare to previous proposed hw assisted ways to bolt memory safety onto C? Like Hardbound, In-Fat, MPX for example.

mwcampbell3• 5 years ago

I'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.

pjmlp7• 5 years ago

As 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.

jrtc2721• 5 years ago

The simple answer is that it actually works for real-world software, is microarchitecturally feasible and flexible, and architecturally enforces non-forgeability (which is crucial allowing in-address-space compartmentalisation of distrusting software). Most schemes that take the metadata-table-on-the-side approach fall down on those last two points. MPX is particularly notorious for tanking performance, having race conditions (because loading the bounds is not atomic with loading the address) and having an extremely limited number of bounds registers (I think 4? which is even worse than the highly constrained register set of 32-bit x86) so you're constantly spilling/reloading bounds data from memory. I don't think any of them have been shown to work across the entire software stack from the kernel to core userspace runtime parts to graphical desktops like KDE.

jacquesm4• 5 years ago

It 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.

phkahler3• 5 years ago

Or test software that has known vulnerabilities and see if it actually prevents them.

pm215• 5 years ago

The "Linux enablement" section of 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.

jrtc2721• 5 years ago

Our 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).

jacquesm4• 5 years ago

Interesting. 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.

netr0ute3• 5 years ago

What about RISC-V?

jrtc2721• 5 years ago

We also have a CHERI-RISC-V specification (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/Flute, 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.

netr0ute3• 5 years ago

Then the HN title is inaccurate.

phkahler3• 5 years ago

How does this compare to testing with address sanitizers?

andsanmar• 5 years ago

Simple, 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.

trasz2• 5 years ago

Apart 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.

phkahler3• 5 years ago

But 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.

fulafel2• 5 years ago

Testing for security bugs means mostly fuzzing these days. AddressSanitizer is added instrumentation, flagging illegal program states even when the test case wouldn't trigger a crash normally.

Fuzzing helps but it's a probabilistic method with fallible search mechanisms, there's going to be cases left that an intelligent adversary can find by reasoning, a different/better fuzzer, better instrumentation, or alt techniques like symbolic execution etc.

mwcampbell3• 5 years ago

I 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.

jrtc2721• 5 years ago

Windows is likely a big task for the same reasons as SMAP (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.

pjmlp7• 5 years ago

That 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• 5 years ago

With 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?

trasz2• 5 years ago

The MIPS and RISC-V CHERI implementations are open, you can audit the BlueSpec. The entire software stack is open too.

Note however that CHERI is not just an implementation; it’s a design, an idea. You can’t backdoor that.

ncmncm• 5 years ago

Anyway, it's harder.

_0w8t2• 5 years ago

I 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.

jrtc2721• 5 years ago

CHERI 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_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.

zeotroph2• 5 years ago

On 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/

jrtc2721• 5 years ago

The 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.

zeotroph2• 5 years ago

Thanks for the explanation!

So these bounds are set by the software (and are guarded against manipulation). Then each read or write to memory is checked against these bounds by the "fine grained MMU" hardware.

amelius• 5 years ago

Every load or store instruction and every instruction fetch must be authorized by an architectural capability.

This sounds great. But on the other hand ... Yikes! What if this tech falls into the hands of a big corporation and some manager needs a raise?

als0• 5 years ago

This isn’t a digital signature or anything like that. Instead, it’s increasing the size of pointers to include bounds and permission rights (R/W/X/etc), plus an extra tag stored somewhere else to prevent forgeries or mitigate corruption. So the only thing big corp gets out of this is software more resilient to memory corruption :-)

jrtc2721• 5 years ago

Then great, they push for the adoption of the technology and the world's computers become more secure. Arm's a big corporation and they're obviously pretty involved, and both Microsoft and Google are invested in the project.

Findecanor• 5 years ago

I remember the mill architecture[1] also claims to have that capability, I think they called these calls "Portals".

The Mill's "Portals" are more intended for inter-process calls than for compartmentalisation within a process. The Mill can have fine-grained protection of memory temporarily given to a callee because protection ranges are separate from paging. I believe there have been several research OS:es that did pass full pages back and forth over IPC, but at the cost of setting these up and restricting them to that purpose.

Because Portals are so cheap they could probably be useful for compartmentalising larger complex applications such as a modern-day web browser into smaller chunks than today.

BTW, Goddard has told that the Mill team once considered a capability-oriented architecture but they chose not to because the model they had in mind broke C's pointer semantics in some way. They have chosen to prioritise compliance with the C spec, so as to be able to market the architecture.

transpute• 5 years ago

Hopefully ARM's MTE (memory tagging extension) will appear in Apple's 2022 SoCs (M2, A16), https://security.googleblog.com/2019/08/adopting-arm-memory-...

(2020) CheriBSD port to Morello, https://www.youtube.com/watch?v=7aVygpgkm1

(2021) GCC support for Morello, https://gcc.gnu.org/pipermail/gcc/2021-July/236868.html

(2021) OSS desktop software stack, 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_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.

pjmlp7• 5 years ago

They already have PAC, although not exactly the same.

saagarjha3• 5 years ago

Right. PAC is largely used for CFI, CHERI/MTE are more general memory corruption mitigations.

dilippkumar• 5 years ago

If 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?

saagarjha3• 5 years ago

129 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• 5 years ago

It'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.

pjmlp7• 5 years ago

The year is 1961 and C is still about 10 years away to become a reality, https://en.wikipedia.org/wiki/Burroughs_large_systems_descri...

staticassertion• 5 years ago

This 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• 5 years ago

This 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..

ProfHewitt3• 5 years ago

Great to see further progress on CHERI!

See the following for theoretical foundations for the work:

Linux 60th Anniversary Keynote

https://t.co/IRe3vpMlWn

jrtc2721• 5 years ago

Your research on actor-based programming models has nothing to do with C/C++ spatial and temporal memory safety.

ProfHewitt3• 5 years ago

Foundation is about rigorously specifying the general Laws of Locality for Actor systems that CHERI implements.

Arm releases experimental CHERI-enabled Morello board

Related Stories