Re: Capabilities, Anybody?

On Mon, 11 Mar 2024 14:50:03 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

Michael S <already5chosen@yahoo.com> writes:

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.
 

 
xrn on linux is not confused (which is not surprising since
linux stores time internally as GMT anyway).
 
Date: 11 Mar 2024 11:10:15 +0000 (GMT)

The issue does not appear to have anything to do with OS. It's all
about parsing of 'Date' header.

For example, in your message it looks like:
Date: Mon, 11 Mar 2024 14:50:03 GMT
Claws mail understand it.

In message of Tim Rentsch it looks like:
Date: Mon, 11 Mar 2024 07:54:07 -0700
Claws mail understand it.

In my messages format is the same as in Tim's.

In messages of Theo the header looks like a mix of yours and ours:
Date: 11 Mar 2024 11:10:15 +0000 (GMT)

The wonders of Postel's law.