zlacker

>>zxombi+(OP)
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.

>>jacque+pq
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).

>>jrtc27+pv
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.

>>jacque+VX
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).

>>jrtc27+W01
I think this is an extremely important and timely development, I sincerely hope that you succeed and will be following the project closely from now on.

One more question: does the CHERI add on introduce new 'uLimit' like limitations, for instance the number of allocatable blocks or will it scale seamlessly with whatever the various memory management functions and system calls provide?

>>jacque+v41
The only thing that gets weird is the primary thread's stack limit, since we need to construct that capability up-front with the right bounds. This means we have a somewhat arbitrary upper limit (which you could make tunable, though I don't think we do, just a #define'd constant) that should be big enough for any reasonable process and reserve all that virtual address space regardless of what the stack limit is (but it's still unmapped and not backed by anything, just a big region of "don't use this as another capability already overlaps with it"). You can then use rlimit(2) to configure your stack limit and the virtual memory subsystem will do the same as it does on non-CHERI, just you won't be able to exceed that threshold, and the capability's bounds for the stack pointer will always cover the maximum possible mapping, not the mapping you're actually using.

Everything else is the same, just "as much as your system can fit (and system policies will let you)". Which will be slightly less, because pointers are bigger, but we don't have any additional tables that impose arbitrary restrictions on what you can do.

>>jrtc27+I61
Ok. Super cool that you have thought so far ahead in designing this. Looking forward to being able to use it in production!