[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <0CA898CF-381C-483F-A8B5-6F0D05026977@apple.com>
Date: Sat, 01 Nov 2025 18:11:48 -0700
From: Oliver Hunt <oliver@...le.com>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: Thiago Macieira <thiago@...ieira.org>, Alejandro Colomar <alx@...nel.org>,
Paul Eggert <eggert@...ucla.edu>, libc-alpha@...rceware.org,
musl@...ts.openwall.com, "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: realloci(): A realloc() variant that works in-place
> On Nov 1, 2025, at 7:18 AM, Florian Weimer <fw@...eb.enyo.de> wrote:
>
> * Oliver Hunt:
>
>>> On Oct 31, 2025, at 10:53 AM, Thiago Macieira <thiago@...ieira.org> wrote:
>>>
>>> On Friday, 31 October 2025 10:31:54 Pacific Daylight Time Paul Eggert wrote:
>>>> On 10/31/25 11:25, Thiago Macieira wrote:
>>>>> I think the Committee would balk at adding a function
>>>>> that takes a pointer to already-freed memory whose purpose is to allow the
>>>>> contents of the new object to be adjusted solely based on arithmetic.
>>>>
>>>> Do you know of any platforms where this does not in fact work? Other
>>>> than sanitizing platforms that go to some lengths to impose the
>>>> Committee's rules even though the hardware would work fine?
>>>>
>>>> If not, then perhaps we can convince the Committee that the mismatch
>>>> between the current rules and reality is causing real harm, and that
>>>> it'd be a win for C's users to change the standard to match reality better.
>>>
>>> Oliver, please comment on ARM64e if you can, for pointer authentication. Think
>>> not just of statically-known pointers like vtables, but the general case of
>>> pointer authentication.
>>
>>
>> I don’t believe ptrauth would really play into this, but MTE does.
>
> I think MTE still works because if realloc changes the tag, the
> pointer changes. The application then has to do the offset-based
> adjustment, which happens to change the tag only.
That’s possible - I’ll have to re-read the thread to get a more thorough understanding of exactly what it being proposed (why hasn’t someone written a formal proposal yet? :D :D )
I only did a very high level scan of the thread after Thiago pinged me, and it seemed like the intent was to be able to access outside of the officially live region on the basis of “knowing” that the memory was available.
My assumption would be an implementation that did do an in place reallocation would update the tags for only the newly active region (so their tags matched the existing one), but it’s interesting as a debugging/testing idea that realloc would always replace the tags even if it does do an inplace realloc so that it is never possible to reuse the old pointer.
For a change I’m not thinking of anything security related, this is my recollection from when I was a TA at uni - a common mistake students would make is to do realloc and keep using their old pointer, because it often worked, and then get confused when it didn’t (this was very early in the "learning C” course work so they were coming from Java, and hadn’t yet actually learned how memory “works”). Having it be an “always fails” path seems useful in such a case.
> (I'm not saying this malloc change is a good idea. I don't know of
> its implications, and if it can be integrated safely with the other
> parts of the languages.)
I’m dubious of it being a good idea, but that’s just based on my general reticence about providing mechanism that functionally expose internal mechanisms of the allocator that operate independently of the abstract machine’s ideas about memory :D As above I’ll need to re-read the thread more thoroughly to understand the exact semantics being proposed.
—Oliver
Content of type "text/html" skipped
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.
