Re: Capabilities, Anybody?

In article <Qry*XE3Ez@news.chiark.greenend.org.uk>,
theom+news@chiark.greenend.org.uk (Theo Markettos) wrote:

The C experience is fairly normal, as long as you are actually
playing by the C rules.  You can't arbitraily cast integers to
pointers - if you plan to do that you need to use intptr_t so
the compiler knows to keep the data in a capability so it can
use it as a pointer later.

Makes sense, though it will require updating of older code for the rules
being more thoroughly enforced. Not a bad thing.

Tricks which store data in the upper or lower bits of pointers are
awkward.

Not compatible with Aarch64 Pointer Authentication, but CHERI should be a
functional replacement anyway.

Changes in a 6M LoC KDE desktop codebase were 0.026% of lines:
https://www.capabilitieslimited.co.uk/_files/ugd/f4d681_e0f23245dace
466297f20a0dbd22d371.pdf

15,000 or so changes. Quite a lot. Is the code backwards-compatible to a
conventional C platform?

Sandboxing involves dividing code into compartments; that involves
some decision making as to where you draw the security boundaries. 
There aren't good tools to do that (they are being worked on).
CHERI offers you the tools to implement whatever compartmentalisation
stategy you wish, but it's not quite as simple as just recompiling.

I have a slightly odd case: the software I work on ships as a great big
shared library that's used in-process by its caller. It isn't any kind of
server, and doesn't use any IPC; in concept it's a huge math library that
asks the caller to allocate memory for it. So it needs to share a heap
with the caller. Presumably that model is workable?

... we're running on FreeBSD

That was a point against my experimenting with Morello when we were
offered it last year; the requirement to port to FreeBSD first. Morello
Linux seems insufficiently mature at present; do you have any idea of the
timescale for it to be robustly usable for porting application code by
someone who isn't experienced in Linux internals?

John