[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA2zVHrtmW6Kgdj6XXAFCXe6Gu3o4=6rTAHaJ+MCprn2Nrq6CQ@mail.gmail.com>
Date: Sun, 14 Dec 2025 15:06:04 -0500
From: James Y Knight <jyknight@...gle.com>
To: musl <musl@...ts.openwall.com>
Cc: Rich Felker <dalias@...c.org>, Bill Roberts <bill.roberts@....com>
Subject: Re: [RFC 00/14] aarch64: Convert to inline asm
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.
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.
