Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: jgd@cix.co.uk (John Dallman)
Newsgroups: comp.arch
Subject: Re: Capabilities, Anybody?
Date: Sun, 10 Mar 2024 17:14 +0000 (GMT Standard Time)
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <memo.20240310171449.4308D@jgd.cix.co.uk>
References: <Qry*XE3Ez@news.chiark.greenend.org.uk>
Reply-To: jgd@cix.co.uk
Injection-Info: dont-email.me; posting-host="cae1fa548a706f5751bda9a68d910e12";
	logging-data="3238093"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+iyRRgtbyEB8jVS7nbpajAgpsfgh4kp08="
Cancel-Lock: sha1:lILKDRZakSHcLKbGWhhPl7QyVnc=
Bytes: 2858

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