Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Capabilities, Anybody?
Date: Mon, 11 Mar 2024 16:10:09 +0200
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <20240311161009.00000923@yahoo.com>
References: <usg40i$1udfo$3@dont-email.me>
	<1951488caf6138e90c4bac62ee6ac41d@www.novabbs.org>
	<_Y_GN.75295$LONb.13164@fx08.iad>
	<usibg4$2ffdn$1@dont-email.me>
	<usif12$2g7eq$1@dont-email.me>
	<usinhj$2i2nn$1@dont-email.me>
	<6b75cd0221ee827b49cd2275f2c65789@www.novabbs.org>
	<Qry*XE3Ez@news.chiark.greenend.org.uk>
	<7da2a6f0e0878f914dee2286db833dc2@www.novabbs.org>
	<Qry*d14Ez@news.chiark.greenend.org.uk>
	<bd0b3b879184fd66b2c90cf4da2491a1@www.novabbs.org>
	<Rry*LM7Ez@news.chiark.greenend.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Info: dont-email.me; posting-host="20135147cba2d202cd079ad5c3141fdd";
	logging-data="3784551"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19goU36eqKqiT+oJm3BIOsNXwli5HHi+m8="
Cancel-Lock: sha1:ADBTzpVgl1DyYZP7rcQnuhJsREM=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3388

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.