Skip to content

FAQ: Background, the 'why'

Jump to bottom
Nathaniel Wesley Filardo edited this page Jul 26, 2021 · 2 revisions

Why contribute now?

The CHERI project began in 2010, and has been a small team of researchers, most of which are housed in a single building. Typically when onboarding a new contributor, someone either flies out to them or they travel to that building.

That model isn’t terribly scalable, and with the announcement of real, physical CHERI hardware landing in 2021, the Arm Morello Board , there is a growing interest, and an increasing number of engineers and companies who want or need to contribute to the project. The UK government will also be funding UK universities and companies to perform research and build demonstrators/prototypes around CHERI as part of the Digital Security by Design initiative.

What are capabilities anyway?

Capabilities as a design concept are relatively old and relatively intuitive: something should only be able to interact with resources for which it has (unforgeable) rights. Capabilities can be viewed as a way to implement the principles of least privilege and privilege separation. They have been implemented in hardware, software, and a combination of the two, at least in a research setting. Wikipedia’s Capability-based security article has a good list of capability supporting systems that managed to escape the lab. Traditionally, cost of re-development/re-implementation or performance has kept capability systems out of wider use.

Do they replace FreeBSD Capsicum capabilities?

They do not. Capsicum capabilities in FreeBSD (and by extension CheriBSD) is analogous to seccomp on Linux. It’s used at a per process level in user space to restrict system calls. Nor are they related to the withdrawn POSIX capabilities.

CHERI by contrast, is an architectural feature that extends existing architectures which can be used for things like low level memory safety. CHERI capabilities are most often used like fat pointers carrying additional benefits. As a general rule, the closer you are tied to the hardware, ie compiler, language runtime, or operating system, the more you care about the CHERI features.

Ideally, a security conscious application would make use of both OS-based sandboxing and CHERI protections, although it may not be aware of the CHERI features it uses through a trusted computing base (like a compiler).

Where are capabilities used in CheriBSD?

CheriBSD is a CHERI-enabled adaptation of the FreeBSD operating system. CheriBSD tries to stay up to date with FreeBSD plus or minus a few weeks. At the time of this writing, userland, the level at which normal applications and users operate, runs in pure capability mode, where old school, unprotected C style pointers are not allowed. The kernel itself however, is still not fully ported over to using capabilities within itself. There is ongoing effort on a pure capability kernel on a branch. It’s one the many areas where we’d love some help.

Is CheriBSD the same as CheriOS ?

CheriBSD is not the same thing as cheriOS. CheriBSD is a CHERI-fied version of FreeBSD, which was designed long before CHERI, and whose internals may not all be able to benefit from all of CHERI’s features. For example, employing CHERI memory safety seems to work well with the UNIX design and implementation, but using CHERI-based compartmentalization requires greater rethinking of OS software abstractions. In contrast, CheriOS is a new microkernel built from scratch with CHERI capability hardware in mind. I have not worked with it, however it’s a very intriguing design space. If that interests you, please see the CheriOS github page and reach out on the dedicated channel on the CHERI CPU slack.

Where can I find out more?

In the immortal words of Lego Batman, “prepare yourself for some….reading”! The whole list of publications can be found on the CHERI Publications page. I don’t recommend you start there. Academic papers represent truth at time of publication, and may no longer be current.

I’ve taken to renaming any CHERI related pdf I download, because the names are not descriptive for end users.

I recommend you go in the approximate following order, using the Architecture document as a reference as you read the other things.

The first version of this appeared on Allison Naaktgeboren's page.

Clone this wiki locally