linux-kernel - Re: [PATCH 05/19] rust: add `compiler

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: <CANiq72kUBy64D_psB2YsBs4evfyGUJO6g2eb5-5xZYg2rVETsw@mail.gmail.com>
Date:   Thu, 9 Dec 2021 20:34:00 +0100
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Miguel Ojeda <ojeda@...nel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        rust-for-linux <rust-for-linux@...r.kernel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Wedson Almeida Filho <wedsonaf@...gle.com>,
        Sven Van Asbroeck <thesven73@...il.com>,
        Gary Guo <gary@...yguo.net>
Subject: Re: [PATCH 05/19] rust: add `compiler_builtins` crate

On Wed, Dec 8, 2021 at 12:02 AM Nick Desaulniers
<ndesaulniers@...gle.com> wrote:
>
> Rather than panic at runtime, could we do some binary post processing
> in Kbuild with $(NM) to error the build if any of the below symbols
> are referenced from .o files produced by .rs sources?

To error the build, we only need to not define them; i.e. the issue is
passing the build. Eventually, we should be able to avoid defining
them (this is what the comment is referring to).

There are other ways around, like providing an in-tree `core`, but it
is best to see if upstream Rust can do it.

> If we provide definitions of these symbols, then I worry about C code
> that previously would have failed to link at build time when
> referencing these will now succeed at linking when CONFIG_RUST=y is
> enabled, but may panic at runtime IF we happen to hit those code
> paths.

It should be fine -- by the time we consider the Rust support
non-experimental, we should not be defining them.

Cheers,
Miguel