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: <6eeba3ce-d66c-45e2-8c34-ad0109ec2ef0@app.fastmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ