|
|
Message-ID: <lhuldkchdxk.fsf@oldenburg.str.redhat.com>
Date: Tue, 11 Nov 2025 14:55:03 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Brooks Davis <brooks@...ebsd.org>
Cc: musl@...ts.openwall.com, Thiago Macieira <thiago@...ieira.org>,
Alejandro Colomar <alx@...nel.org>, libc-alpha@...rceware.org, "A.
Wilcox" <AWilcox@...cox-tech.com>, L??n??rd Szolnoki
<cpp@...ardszolnoki.com>, Collin Funk <collin.funk1@...il.com>, Arthur
O'Dwyer <arthur.j.odwyer@...il.com>, Jonathan Wakely
<jwakely@...hat.com>, "Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
* Brooks Davis:
> On Fri, Oct 31, 2025 at 09:54:52PM -0600, Paul Eggert wrote:
>> On 10/31/25 17:27, Thiago Macieira wrote:
>> > I don't think you are because imposing this requirement would imply it will
>> > never memcpy() the data to a new location and that would break quite a lot of
>> > applications that depend the ability to grow a block so long as there's heap
>> > available.
>>
>> You're right I'm not saying that. All I'm saying is that when R=realloc(P,N)
>> succeeds, you can assume that you can adjust old pointers into the object
>> addressed by P by adding R-P to them. The C standard says this results in
>> undefined behavior; all that we need to do is fix the C standard to say it's
>> well-defined (because it is on practical platforms).
>
> As described (adding R-P), this is broken on CHERI systems. You must
> derive new pointers from R as pointers derived from P will be out of
> bounds (and with revocation will become invalid at some indeterminate
> point.) In CheriBSD, we do take care to preserve the invariant that
> either the pointer is unchanged including bounds or we've done a
> malloc-memcpy-free.
Would this work?
new->field = (decltype(new->field)) ((char *) new
+ ((uintptr_t) new->field
- (uintptr_t) old));
That should have correct provenance.
> MTE is likely to have similar issues with pointer updates unless the
> implementer ensures that realloc returns pointers of the same color.
Only if pointer additions wrap around, but that would be a problem even
without MTE: ptrdiff_t cannot represent all potential pointer offsets
anyway.
Thanks,
Florian
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.