Re: Capabilities, Anybody?

On 3/8/2024 7:51 PM, MitchAlsup1 wrote:

I have been in CPU design for a very long time. I did a HS level design (calculator) in 1968 3 years before the Bomar Brain, did
a #60 design in college as a Jr, and started doing professional
designs (Mc 88100) in 1983.
 With all this background and long term in this career, I can say
without a trace of doubt, that I am not <yet> smart enough to do
a capabilities ISA/system and get it out the door without errors.
 

Yeah.
As I see it, they seem to have a few drawbacks:
   Overheads (in terms of performance and memory);
   Not foolproof as a security model.
Most of this is assuming an approach similar to CHERI (rather than, say, one based mostly on opaque handles or similar, which is its own thing).
A "practical" implementation of a C runtime on top of a capability system is likely to have internal security holes, almost as a necessity of implementing the C runtime (and giving typical expected C behaviors).
The big concern is the possibility of gaining access to "do anything" capabilities:
It is unclear if a generally useful C runtime can be implemented without them (absent imposing additional restrictions on the language, and thus making portability harder);
The moment an application can get access to such a capability, a security scheme based on capabilities is blown;
Within the existing model, any capability which is reachable by the C runtime, is indirectly reachable from the program being run (provided it can figure out a path to get access to such a capability).
If one disallows "unsafe" free-form pointer casting, this could potentially eliminate this route, but a lot of existing C code would break as well.
It seems like, if people can master the trickery needed to figure out how to exploit buffer overflows (well proven at this point), they already have the tools needed to figure out how to break through a capability system in such an implementation.
Granted, it would be "harder" than it would be in a conventional flat address space; but to claim it as a security feature for unsafe or untrusted code, requires something stronger than, well, "you need to exploit some arcane black-magic series of pointer casts and dereferences or similar to get at what you really want". One needs a mechanism where no such paths are possible (either because access is entirely prevented, or the security-breaking capabilities do not exist).
Well, either this, or turn most non-trivial runtime calls (such as "malloc()") into system calls.
But, OTOH, if they are running a mostly unmodified GLIBC or Newlib, such an exploit path almost certainly exists.
Well, unless someone knows something I don't, and there is a way to pull all this off in a way that doesn't have any implicit holes in the C implementation (and also doesn't render the language "basically unusable").
Though, making capability-based security work might be easier if one were using exclusively languages where "type safely" and "memory safety" were the default option (say, it would probably work much better with a language like C# or Java). But, in this case, the main "powers" of the capability system would mostly be rendered moot.
If one passed them off as mostly:
   Can be used to prevent buffer overflow exploits;
   Can be useful to detect memory-access bugs as soon as they happen;
   Avoids causing programs to be "slow as molasses" when using them;
   ...
This is at least more in line with what seems realistic.
But, in this latter case, a full capability system is almost a little overkill.
Though, a watered down variant, such as "hardware-assisted bounds-checked pointers" can be useful (and may also use a similar encoding scheme to a capability system).
But, one can cut a lot of corners to make things cheaper (such as no memory tagging, minimal new special-purpose instructions, ...).
But, as such, can't claim them as being capabilities.
I experimented with two schemes:
   64 bit pointers:
     (47: 0): Address
     (63:48): Bounds Tag
       (55:48): Size, as a E5.F3 microfloat
       (59:56): Offset Bias (Same exponent as microfloat)
   128 bit pointers:
     ( 47:  0): Address (Low)
     ( 63: 48): Bounds Tag (A)
     (111: 64): Address (High)
     (127:112): Bounds Tag (B)
There were specialized instructions for things like adjusting pointers, and for checking an access for bounds violation (which would then raise an exception), ...
The bounds checking was, at best, a coarse approximation (and trying to take a pointer out-of-bounds would generally cause it to "self-destruct", partly as the scheme couldn't represent out-of-bounds addresses).
When using it for stack and global arrays, a partial option was to pad the arrays (it would be padded up to a size and alignment that could be represented with the tag; with the in-memory storage representing the "worst case" bounds). Likewise, because the bounds were approximate, it was still often possible to go "slightly out of bounds" before the fault tripped, but the padding scheme allowed making it so that "nothing of relevance" exists in this "slightly out-of-bounds" space.
So, say, with this feature enabled, nearly all such arrays were roughly 25% bigger in memory due to the padding constraints.
As I see it, this scheme similarly offers no additional protection against malicious code, but can offer protection against buffer overflow exploits (and was semi-useful as a debugging feature; well, after fixing up the storm of subtle out-of-bounds accesses that may have been lurking in the code).
Meanwhile, more traditional mechanisms for untrusted code, like running them in a restrictive sandbox, are likely still to be workable (provided there is no real way for the program being run to break free of the sandbox).

On the other hand, My 66000 Architecture is immune to most attack
strategies now in vogue:: Return Oriented Programming, RowHammer,
Spectré, GOT overwrites, Buffer Overflows,... All without having
any semblance of capabilities; and all without any performance
degradations other than typical cache and TLB effects.

I had decided to instead split the problem into sub-parts:
   The possibility of page-level ACL checking;
   The possibility of bounds-checked pointers;
   More conventional "tried and true" methods.
And, also limit the scope of the claims:
Page-level ACL checks:
A task can only access pages for which access has been granted to it via the ACL (to the task's PID, or via an additional key in the keyring).
This mostly assumes that the kernel arbitrates what has access to what.
Bound's checked pointers:
If the pointers are used "correctly", any out-of-bounds accesses will trap (and works in a way that is mostly invisible to normal C code, but does have a non-zero ABI and performance impact).
Mostly sufficient to help protect against things like buffer-overflow exploits, but would be entirely ineffective against malicious code.
Granted, my existing "OS" is still painfully weak in these areas, as memory-protection is still virtually non-existant (not entirely moved programs to usemode, since this would still mean trying to go and finish porting all the test programs over to TKGDI and eliminating the remaining use of bare hardware interfaces).
Though, at present, this is mostly programs like ROTT and similar.
..