Re: Capabilities, Anybody?

On 3/9/2024 1:58 PM, Robert Finch wrote:

On 2024-03-09 1:56 p.m., BGB wrote:

On 3/9/2024 9:09 AM, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

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

>
On the gripping hand, the Burroughs Large systems capability based
design is still processing data almost sixty years after the original
B5500 was introduced.
>
There CHERI designs on silicon in existence
>
https://www.morello-project.org/

>
It is doable, at least.
>
Main open question is if they can deliver enough on their claims in a way that justifies the cost of the memory tagging (eg, where one needs to tag whether or not each memory location holds a valid capability).
>

Capabilities sounds like something previously implemented in mainframe class computers. It reminds me of games where the units have capabilities.
 The memory tagging could be done with BRAM accessed in parallel to the DRAM, but there is not enough BRAM to provide tags for every capabilities location in my test system. But, if capabilities were located in capabilities pages it might be possible to implement some sort of demo. They say in the text it was expected the capabilities descriptor would come before an object being protected. For instance, 16 BRAMs could be dedicated to providing an extra tag bit for a 1k size page of DRAM memory. Where there is 512MB of DRAM. The capabilities would be protecting 1kB regions of memory. That might be okay for some things like stack allocations by the OS, or context save areas. Mid to large sized objects. Capabilities do not seem practical for small objects. Taking at least 16B, probably would not want to use them for less than 16B. 50% overhead.
 For Femtiki OS, I have a single object describing an array of values. For instance messages which are small objects, are described with a single object for an array of messages. It is too costly to use an object descriptor for each message.

For a CHERI like approach, one would need a tag of 1 bit for every 16 bytes of RAM (to flag whether or not that RAM represents a valid capability).
For the combination of RAM sizes and FPGAs I have access to, this is non-viable, as I would need more BRAM for the tag memory than exists in the FPGAs.
In effect, this will mean needing another smaller cache which is bolted onto the L2 cache or similar, whose sole purpose is to provide tag-bits (and probably bounce requests to some other area of RAM which contains the tag-bits memory).

>
As I see it, "locking things down" would likely require turning things like "malloc()/free()", "dlopen()/dlsym()/...", etc, into system calls (and generally giving the kernel a much more active role in this process).
>

I think this may not be necessary, but I have to read some more. The capabilities have transfer rules which might make it possible to use existing code. They have ported things over to Riscv. It cannot be too mountainous a task.
 

You can make it work, yes, but the question is less "can you make it work, technically", but more:
Can you make it work in a way that provides both a fairly normal C experience, and *also* an unbreakable sandbox, at the same time.
My skepticism here is that, short of drastic measures like moving malloc and libdl and similar into kernel space, it may not be possible to keep the sandbox secure using solely capabilities.
ASLR could help, but using ASLR to maintain an image of integrity for the capability system would be "kinda weak".
One could ask though:
   How is my security model (with Keyrings) any different?
Well, the partial answer mostly is that a call that switches keyrings is effectively accomplished via context switches (with the two keyrings effectively running in separate threads).
So, like, even if the untrusted thread has a pointer to the protected thread's memory, it can't access it...
Though, a similar model could potentially be accomplished with conventional page-tables, by making pseudo-processes which only share parts of their address space with another process (and the protected memory is located in the non-shared spaces, with any calls between them via an RPC mechanism).
Had considered mechanisms which could pull this off without a context switch, but most would fall short of "acceptably secure" (if a path exists where a task could modify its own KRR or similar, this mechanism is blown).
My bounds-checking scheme also worked, but with a caveat:
It only works if code does not get "overly clever" with the use of pointers.
So, it worked well enough to where I was able to enable full bounds-checking in Doom and similar, but was not entirely transparent to some of the runtime code. If you cast between pointers and integers, and manipulate the pointer bits, there are "gotchas".
A full capability system is going to have a similar restriction.
Either pointer<->integer casting would need to be disallowed, or (more likely), turned into a runtime call which can "bless" the address before returning it as a capability, which would exist as another potential attack surface (unless, of course, this mechanism is itself turned into a system call).
OTOH:
If one can't implement something like a conventional JavaScript VM, or if it takes a significant performance hit, this would not be ideal.

Or, change the description, as being mostly a tool to eliminate things like buffer overflow exploits and memory corruption, and as a fairly powerful debugging feature.
>
But, say, note that it would not be sufficient, say, for things like sandboxing hostile code within a shared address space with another program that needs to be kept protected.
>
>
Granted, the strength could likely be improved (in the face of trying to prevent hostile code from being able to steal capabilities) through creative use of ASLR. Along with ABI features, such as "scratch register scrubbing" (say, loading zeroes into scratch registers on function return, such as to prevent capabilities from being leaked through via registers), marking function pointers as "Execute Only" etc.
>
As noted, a capability system would likely still be pretty strong against things like buffer overflows (but if only being used to mitigate buffer overflows, is a bit overkill; so the main "interesting" case is if it can be used to make an "unbreakable sandbox" for potentially hostile machine code).
>
>
*: If it is possible to perform a Load or (worse, Capability Load) through a function pointer, this is likely to be a significant attack vector. Need to make it so that function pointers can only be used to call things. Protecting against normal data loads would be needed mostly to try to prevent code from being able to gain access to a known pointer and possibly side-step the ASLR (say, if it can figure out that the address it wants to access is reachable from a capability that the code has access to).
>
>
>
Though, on my side of things, it is possible I could revive a modified form of the 128-bit ABI, while dropping the VAS back down to 48 bits, and turn it into a more CHERI-like form (with explicit upper and lower bounds and access-enable flags, rather than a shared-exponent size and bias scheme).
>

Yeah, IMO explicit upper and lower bounds would be better even though it uses more memory. The whole manipulation of the bounds is complex. I sketched out using a 256b capability descriptor. Some of the bits can be trimmed from the bounds if things are page aligned.
 

IIRC, they were using 128-bit descriptors with a bit-slicing scheme.
So, say, if I were to do similar (within my existing pointer layout):
   ( 27:  0): Base Address
   ( 47: 28): Shared Address (47:28)
   ( 63: 48): Type Tag Bits
   ( 87: 64): Lower Bound (27:4)
   (111: 88): Upper Bound (27:4)
   (    112): Base Adjust
   (    113): Lower Bound Adjust
   (    114): Upper Bound Adjust
   (127:115): Access Flags / Etc
Though, this particular encoding would limit bounds-checking to a 256MB region, which is lame (or eat more tag bits, and have slightly bigger regions).
Adding an exponent could fix this, but would increase the LUT cost.
This sort of scheme does have the advantage of it being straightforward encode and decode the bounds (with the presumption that the bounds-checking is done in linear address space).
OTOH, doing the bounds checking in shared-exponent floating-point form is arguably kinda fiddly and weird...
Another possibility would be to do it as a bigger variation of my smaller bounds-checking schemes:
   ( 47:  0): Base Address
   ( 63: 48): Type Tag Bits
   ( 83: 64): Size
   ( 89: 84): Exponent
   (111: 90): Bias (possibly sign-extended in this form)
   (127:112): Access Flags / Etc
In this case, one does not normally unpack the bounds, but rather operates inside the exponent space, and uses adjustments to the base address to adjust the bias field (which in this case, would effectively encode the relative location of the base pointer relative to the capability size).
Which could have, say, a 16-byte granularity up to around 8MB, and would then go to a coarser granularity for larger arrays.

Can note the XMOV.x and XLEA.x instructions were already defined as having the needed semantics, unlike with 64-bit pointers, where the bounds-checking semantics were opt-in. Would need to add instructions for things like sub-setting the capabilities, etc.
>
In this case, register and memory tagging could be added, possibly with a "Capability Enable" flag somewhere, which would modify some behaviors:
   XMOV.x will trap if the address is not flagged as a valid capability;
   The normal MOV.x instructions would be disallowed with this flag set.
     With possibly a partial exception for PC rel.
     Handling of global registers may need some rethinking.
   The XMOV instruction would be required to MOV capabilities;
     A pair of MOV instructions would no longer be valid.
>
>
Though, likely, this could be used in combination with the existing security model, and with ASLR (well, because, if one has a good RNG, this can be moderately effective; can't forge access to things if there is no way to figure out where they are; and ASLR and page-level protection can still offer a line of defense if the program can figure out a hole to sidestep the capability system).
>
Though, still unclear how to prevent a program from "stealing" other images global registers. Could ALSR the PBO indices (used for reloading the Global Pointer), and if it is not possible to read through a function pointer, it may make it difficult to guess the PBO index for something like a shared library.
>
An approach used by something like ELF FDPIC would not be ideal, as the function call mechanism would itself expose the capability of the callee's GOT, which could likely be mined for capabilities to other things, ...
>
>
>
It is likely that the capability memory tagging would need to be managed by the L2 cache. Would need some mechanism for the tag-bits memory (say, 2MB for 256MB at 1b per 16B line). Would also need to somehow work this flag bit into the ringbus messaging.
>
Though, in the immediate future, this wouldn't gain much in my case.
>
...
>
>