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?