linux-kernel - Re: Allow data races on some read/write operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <88456D33-C5CA-4F4F-990E-8C5F2AF7EAF9@gmail.com>
Date: Tue, 4 Mar 2025 12:18:28 -0800
From: comex <comexk@...il.com>
To: Ralf Jung <post@...fj.de>
Cc: Boqun Feng <boqun.feng@...il.com>,
 Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>,
 Daniel Almeida <daniel.almeida@...labora.com>,
 Benno Lossin <benno.lossin@...ton.me>,
 Abdiel Janulgue <abdiel.janulgue@...il.com>,
 dakr@...nel.org,
 robin.murphy@....com,
 rust-for-linux@...r.kernel.org,
 Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>,
 Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Trevor Gross <tmgross@...ch.edu>,
 Valentin Obst <kernel@...entinobst.de>,
 linux-kernel@...r.kernel.org,
 Christoph Hellwig <hch@....de>,
 Marek Szyprowski <m.szyprowski@...sung.com>,
 airlied@...hat.com,
 iommu@...ts.linux.dev,
 lkmm@...ts.linux.dev
Subject: Re: Allow data races on some read/write operations

> On Mar 4, 2025, at 11:03 AM, Ralf Jung <post@...fj.de> wrote:
> 
> Those already exist in Rust, albeit only unstably: <https://doc.rust-lang.org/nightly/std/intrinsics/fn.volatile_copy_memory.html>. However, I am not sure how you'd even generate such a call in C? The standard memcpy function is not doing volatile accesses, to my knowledge.

The actual memcpy symbol that exists at runtime is written in assembly, and should be valid to treat as performing volatile accesses.

But both GCC and Clang special-case the memcpy function.  For example, if you call memcpy with a small constant as the size, the optimizer will transform the call into one or more regular loads/stores, which can then be optimized mostly like any other loads/stores (except for opting out of alignment and type-based aliasing assumptions).  Even if the call isn’t transformed, the optimizer will still make assumptions.  LLVM will automatically mark memcpy `nosync`, which makes it undefined behavior if the function “communicate[s] (synchronize[s]) with another thread”, including through “volatile accesses”. [1]

However, these optimizations should rarely trigger misbehavior in practice, so I wouldn’t be surprised if Linux had some code that expected memcpy to act volatile…

But I’m not familiar enough with the codebase to know whether such code actually exists, or where.

(Incidentally, there is a compiler flag to turn the memcpy special-casing off, -fno-builtin.  I pretty much expected that Linux used it.  But I just checked, and it doesn’t.)

For Rust, I don’t know why we haven’t exposed volatile_copy_memory yet.  All I can find are some years-old discussions with no obvious blockers.  I guess nobody has cared enough.  There is also a somewhat stagnant RFC for *atomic* memcpy. [2]

[1] https://llvm.org/docs/LangRef.html, search for 'nosync'
[2] https://github.com/rust-lang/rfcs/pull/3301