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]

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

On Thu, Feb 8, 2024, at 23:56, Valentin Obst wrote:
>> -#else
>>  extern __must_check unsigned long
>>  _copy_from_user(void *, const void __user *, unsigned long);
>> -#endif
>
> This function is now unconditionally declared, but only defined if
> `!defined(INLINE_COPY_FROM_USER) || defined(CONFIG_RUST)`, i.e., in the
> common case where it is inlined and Rust is disabled this can lead to
> link-time problems if someone decides to use it.

Yes, that is intentional.

If someone tries to use it when the declaration is not there,
they just get a compile-time error, which is not all that
different from a link-time error in practice.

It's unlikely to make a difference here, but enclosing
declarations in an #ifdef is annoying when you want to
reference it from somewhere that is parsed by the compiler
but not called without the respective options.

The if(IS_ENABLED()) and PTR_IF() constructs in particular
only work when the unused functions are still declared.

       Arnd