Re: Capabilities, Anybody?

On 11 Mar 2024 11:10:15 +0000 (GMT), Theo Markettos
<theom+news@chiark.greenend.org.uk> wrote:

MitchAlsup1 <mitchalsup@aol.com> wrote:

Theo Markettos wrote:

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.

 
So how to you "encode" a petaByte array ?? of megaByte structs in a capability ??

>
You create a capability with petabyte-scale bounds.  The precision of the
bounds may be limited, which means that you can't ram something else right
up against the end or beginning of the array if they aren't sufficiently
aligned.  This is in practice not a problem: slab allocators will round up
your address before they allocate the next thing, and most OSes won't
populate the rounded up space with pages anyway.

By default Windows will populate allocated space. You have to
explicitly use the virtual memory api to avoid it.  8-(

When you take a pointer to an array element, then it has megabyte scale
bounds and they can be represented with more precision.  If your struct
elements are of an arbitrary size and packed together at the byte level then
you either have to live with the bounds giving rights to slightly more than
a single struct element, or you decide that is unacceptable and pad the
struct size up to the next representable size (just like regular non-packed
structs enforce certain alignment), and pay a small memory overhead for
that (<0.25%).  That's a security decision you can make one way or another.
>
Theo