linux-kernel - Re: [PATCH v2 2/4] uaccess: always export _copy_[from|to]_user with CONFIG

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: <4f0eb08d-bb5d-4544-aeba-ac9d8a663005@app.fastmail.com>
Date: Sat, 10 Feb 2024 12:07:14 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Kees Cook" <keescook@...omium.org>, "Alice Ryhl" <aliceryhl@...gle.com>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Alex Gaynor" <alex.gaynor@...il.com>,
 "Wedson Almeida Filho" <wedsonaf@...il.com>,
 "Boqun Feng" <boqun.feng@...il.com>, "Gary Guo" <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 "Benno Lossin" <benno.lossin@...ton.me>,
 "Andreas Hindborg" <a.hindborg@...sung.com>,
 "Alexander Viro" <viro@...iv.linux.org.uk>,
 "Andrew Morton" <akpm@...ux-foundation.org>,
 "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
 Arve Hjønnevåg <arve@...roid.com>,
 "Todd Kjos" <tkjos@...roid.com>, "Martijn Coenen" <maco@...roid.com>,
 "Joel Fernandes" <joel@...lfernandes.org>,
 "Carlos Llamas" <cmllamas@...gle.com>,
 "Suren Baghdasaryan" <surenb@...gle.com>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
 "Christian Brauner" <brauner@...nel.org>
Subject: Re: [PATCH v2 2/4] uaccess: always export _copy_[from|to]_user with
 CONFIG_RUST

On Sat, Feb 10, 2024, at 01:15, Kees Cook wrote:
> On Thu, Feb 08, 2024 at 03:47:52PM +0000, Alice Ryhl wrote:
>>  	unsigned long res = n;
>>  	might_fault();
>>  	if (!should_fail_usercopy() && likely(access_ok(from, n))) {
>> +		/*
>> +		 * Ensure that bad access_ok() speculation will not
>> +		 * lead to nasty side effects *after* the copy is
>> +		 * finished:
>> +		 */
>> +		barrier_nospec();
>
> This means all callers just gained this barrier. That's a behavioral
> change -- is it intentional here? I don't see it mentioned in the commit
> log.

My bad, I probably should have explained it when I did the
patch as this is very subtle:

The barrier_nospec() definition is a nop on everything other
than x86 and powerpc, but those two were using the out-of-line
version that did in fact use it.

After this patch, the out-of-line function calls the inline
function, so it needs to be added here to keep the behavior
unchanged on the architectures that need it. For the rest,
this change has no effect.

     Arnd