linux-kernel - Re: [PATCH] rust: page: add volatile memory copy methods

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] [day] [month] [year] [list]

Message-ID: <aYFKbWfQmTInYy91@tardis.local>
Date: Mon, 2 Feb 2026 17:07:57 -0800
From: Boqun Feng <boqun@...nel.org>
To: Andreas Hindborg <a.hindborg@...nel.org>
Cc: Gary Guo <gary@...yguo.net>, Alice Ryhl <aliceryhl@...gle.com>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>, Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>, linux-mm@...ck.org,
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: page: add volatile memory copy methods

On Sat, Jan 31, 2026 at 10:31:13PM +0100, Andreas Hindborg wrote:
[...]
> >>>>
> >>>> For __user memory, because kernel is only given a userspace address, and
> >>>> userspace can lie or unmap the address while kernel accessing it,
> >>>> copy_{from,to}_user() is needed to handle page faults.
> >>>
> >>> Just to clarify, for my use case, the page is already mapped to kernel
> >>> space, and it is guaranteed to be mapped for the duration of the call
> >>> where I do the copy. Also, it _may_ be a user page, but it might not
> >>> always be the case.
> >>
> >> In that case you should also assume there might be other kernel-space users.
> >> Byte-wise atomic memcpy would be best tool.
> >
> > Other concurrent kernel readers/writers would be a kernel bug in my use
> > case. We could add this to the safety requirements.
> >
> 
> Actually, one case just crossed my mind. I think nothing will prevent a
> user space process from concurrently submitting multiple reads to the
> same user page. It would not make sense, but it can be done.
> 
> If the reads are issued to different null block devices, the null block
> driver might concurrently write the user page when servicing each IO
> request concurrently.
> 
> The same situation would happen in real block device drivers, except the
> writes would be done by dma engines rather than kernel threads.
> 

Then we better use byte-wise atomic memcpy, and I think for all the
architectures that Linux kernel support, memcpy() is in fact byte-wise
atomic if it's volatile. Because down the actual instructions, either a
byte-size read/write is used, or a larger-size read/write is used but
they are guaranteed to be byte-wise atomic even for unaligned read or
write. So "volatile memcpy" and "volatile byte-wise atomic memcpy" have
the same implementation.

(The C++ paper [1] also says: "In fact, we expect that existing assembly
memcpy implementations will suffice when suffixed with the required
fence.")

So to make thing move forward, do you mind to introduce a
`atomic_per_byte_memcpy()` in rust::sync::atomic based on
bindings::memcpy(), and cc linux-arch and all the archs that support
Rust for some confirmation? Thanks!

[1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1478r5.html

Regards,
Boqun

> 
> Best regards,
> Andreas Hindborg
> 
>