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.
Arm releases experimental CHERI-enabled Morello board
41–50 of 84 posts
Re: Arm releases experimental CHERI-enabled Morello board
#42On 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)?
Re: Arm releases experimental CHERI-enabled Morello board
#43> 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/
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…
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.
Re: Arm releases experimental CHERI-enabled Morello board
#44Hopefully 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.
Re: Arm releases experimental CHERI-enabled Morello board
#45On 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 functi…
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.
Re: Arm releases experimental CHERI-enabled Morello board
#46Hopefully 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... >…
They already have PAC, although not exactly the same.
Re: Arm releases experimental CHERI-enabled Morello board
#47Earlier quoted context omitted.
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…
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,…
> Yes, the use of CHERI to protect unsafe code in memory-safe languages like Rust is of interest to us.
Have you found that the relative difficulty of bootstrapping Rust on a new architecture, as mentioned in [1], has hindered your team's ability to research this? Or is it not as bad with CHERI on ARM, because aarch64 is already a Rust tier 1 platform?
[1]: https://drewdevault.com/2022/01/15/2022-01-15-The-RISC-V-exp...
Re: Arm releases experimental CHERI-enabled Morello board
#48It 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.
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 wrapp…
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.
Re: Arm releases experimental CHERI-enabled Morello board
#49Earlier quoted context omitted.
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 wrapp…
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.
Similarly if you really want mass market adoption then you need a Windows port, otherwise most consumer PCs will remain without it, and for mobile adoption you want an iOS port (though Android does at least contribute a sizeable chunk). Porting FreeBSD does, however, not just serve as a PoC but also let you port all the standard third-party software that runs on all Unix-like OSes (most ports need few if any changes, but with tens of thousands of software packages out there it does add up if you want a full set of packages available), as well as being a reference implementation for other CHERI OSes to use when being ported since we'll likely have already encountered most of the friction points they do. Plus FreeBSD has its Linuxulator which provides a binary compatibility layer for Linux binaries, so you could even develop parts of a CHERI GNU/Linux userspace on top of that without a real CHERI Linux kernel implementation (we have a proof of concept port of the Linuxulator, but it's not currently fully fleshed out, in part because there wasn't even a proper CHERI Linux ABI defined by Arm at the time).
Re: Arm releases experimental CHERI-enabled Morello board
#50I 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.
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.