[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c3d03f81-b1fb-414d-9701-76cc228c1e63@gmail.com>
Date: Mon, 15 Dec 2025 17:18:44 -0500
From: Demi Marie Obenour <demiobenour@...il.com>
To: musl@...ts.openwall.com, James Y Knight <jyknight@...gle.com>
Cc: Rich Felker <dalias@...c.org>, Bill Roberts <bill.roberts@....com>
Subject: Re: [RFC 00/14] aarch64: Convert to inline asm
On 12/14/25 15:06, James Y Knight wrote:
> On Sat, Dec 13, 2025, 9:23 PM Demi Marie Obenour <demiobenour@...il.com>
> wrote:
>
>> There is code in the wild that relies on memcpy not actually causing
>> data races, even though the C standard says otherwise. The problem is
>> that the standard provides literally no option for accessing memory
>> that may be concurrently modified by untrusted code, even doing so
>> in assembly is perfectly okay.
>>
>> To avoid data races, this code would need to be rewritten to use
>> assembly code for various architectures. I doubt this is a feasible
>> solution.
>>
>> The proper fix is for the standard to include bytewise-atomic memcpy.
>> Until then, people will use hacks like this.
>> As a quality of implementation matter, I strongly recommend that all
>> accesses by memcpy() to user buffers happen in assembly code.
>>
>
> I don't see how software could be usefully relying on memcpy being
> implemented in asm for correctness/security, when common C compilers
> recognize and optimize calls to memcpy under a data-race-free assumption
> regardless of how the C library implements the out-of-line version of the
> function.
Makes sense. This is a case where the only way to get optimal
performance is to hand-write assembly code. There is no way to
avoid undefined behavior without significantly over-constraining
the compiler.
What I really want is to be able to disable the data-race-free
assumption with a compiler switch. It makes anything dealing with
shared memory a nightmare, and (to the best of my understanding)
the performance gain is limited at best.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
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.
