Re: Capabilities, Anybody?

On 3/10/2024 3:32 PM, Theo Markettos wrote:

MitchAlsup1 <mitchalsup@aol.com> wrote:

Theo Markettos wrote:
>

MitchAlsup1 <mitchalsup@aol.com> wrote:

BGB wrote:
<snip>

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.

>

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.

>
As a 'for instance' how does one take a capability and align it to a cache
line boundary ?? Say in/after malloc() ?!?

 I'm not sure what you mean:
 Capabilities are 128-bit fields stored aligned in memory.  It's not allowed
to store a capability that isn't 128-bit aligned.  Those naturally align
with cache lines.  Every 128 bits has a tag associated with it, stored
together or apart (various schemes discussed in my previous posts).
 The memory it points to can be arbitraily aligned.  It is just a 64-bit
pointer.  You dereference it using 8/16/32/64/128 bit load and store
instructions in the usual datapath (either explicitly using 'C load'/'C
store' instructions or switching to a mode where every regular load/store
implicitly dereferences a capability rather than integer pointer)
 The bounds have a certain representation limits, because they're packing
192+ bits of information into a 128 bit space.  This boils down to an
alignment granularity: eg if you allocate a (1MiB+1) byte buffer the bounds
might be 1MiB+64 (or whatever, I can't remember what the rounding is at this
size).  malloc() should ensure it doesn't hand out that memory to somebody
else; allocators typically do this anyway since they use slab allocators
which round up the allocation to a certain number of slabs.
 There is a trickiness if somebody wants to generate a capability to a
subobject in the middle of a large object that isn't aligned: load in a
4.7GiB DVD wholesale into memory and try to generate a capability to a block
of frames in the middle of it, which is potentially large and yet the base
is unaligned, which would cause a loss of bounds precision (somebody could
access the frame before or after).  It's possible to imagine things like
that, but we've not seen software actually do it.
 I'm not sure how any of these relate to cache lines?  Aside for ensuring the
caches store capabilities atomically and preserve tags, any time you
dereference them they work just like regular memory accesses.
 If you mean you ask malloc for something you later want to align to a cache
line, you ask for something larger increment the pointer to be cache
aligned, in the normal way:
 #include <cheriintrin.h>
...
// 64 byte cache lines
ptr = malloc(size+63);  // leave extra space for rounding up
offset = ptr & 0x3F;
ptr += (0x40 - offset); // round up to cache line
 and then increment the base bound to match the new position of 'ptr' and set
the top to be ptr+size:
 ptr = cheri_bounds_set(ptr, size);

Something akin to my old alignment code:
https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ
https://pastebin.com/raw/f37a23918
#define RALLOC_ALIGN_UP(mp_ptr, mp_align) \
   ((void*)( \
     (((ralloc_uintptr_type)(mp_ptr)) + ((mp_align) - 1)) \
     & ~(((mp_align) - 1)) \
   ))
Aligning and padding to cache lines is critical for certain algorithms.