Re: Capabilities, Anybody?

John Dallman <jgd@cix.co.uk> wrote:

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.

Indeed.

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.

I think they can theoretically coexist - ie you can have an authenticated 64
bit pointer which looks like an integer as far as the capability checks are
concerned, but if you don't try to dereference it as a capability then
that's ok.  (Morello doesn't implement PA as it's based on a prior
microarchitecture)

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?

Should be - it's mostly making things play by the rules.  Once they play by
the rules then it means they will work the same (or less buggily) on a
regular C platform.

The above link describes the changes - a number being replacing 'long' with
intptr_t, some undefined behaviour, bad use of realloc().  Some of it was
modernisation of old codebases (eg add C11 atomics), other changes were just
to make optional code that isn't currently available (eg no OpenGL available
in VNC).

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?

Do you want to compartmentalise that shared library, ie put in trust
boundaries between the library and its caller?

If you just want to run the shared library as-is, you can recompile it and
get bounds checking etc.  If you want to have some kind of trust boundary
(eg the library doesn't trust the app, or the app doesn't trust the library)
then you would need to put in a compartment boundary between the two.  In
that case it might make sense for the memory allocator to be its own
compartment; the capabilities it hands out should be usable by both app and
library.

... 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?

FreeBSD is more advanced, in part because it's had more development effort
on it over the years and partly since it's less of a moving target (Linux
has huge amounts of churn).  That means more things have capability support
in the kernel and userspace (including a lot of packages available).

I believe Morello Linux is able to support console-mode apps - ie it has
support context switching and use of capabilities in userspace, with some
support in glibc.  I believe there is now a dynamic linker, but not sure of
the status.  There is only limited use of capabilities in the kernel, so
anything to do with kernel compartmentalisation would be more work.  I think
someone was working on building Debian packages pure-capability - I haven't
heard the current status of that work.

https://www.morello-project.org/cheri-feature-matrix/
has a comparison table.

Theo