zlacker

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+(OP)
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+z3
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+M5
Ok. Super cool that you have thought so far ahead in designing this. Looking forward to being able to use it in production!