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

Your time stamp (most likely +0000 part) confuses my Claws
Mail newsreader. I wonder if others see similar problem.