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: <20220829181133.00005f01@garyguo.net>
Date:   Mon, 29 Aug 2022 18:11:33 +0100
From:   Gary Guo <gary@...yguo.net>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Miguel Ojeda <ojeda@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, patches@...ts.linux.dev,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Wedson Almeida Filho <wedsonaf@...gle.com>,
        Sven Van Asbroeck <thesven73@...il.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Björn Roy Baron <bjorn3_gh@...tonmail.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH v9 09/27] rust: add `compiler_builtins` crate

On Wed, 24 Aug 2022 11:38:46 -0700
Nick Desaulniers <ndesaulniers@...gle.com> wrote:

> Another idea I had, and Ard mentioned to me this morning that efistub
> does something similar:
> 
> I think objcopy can rename symbol references.  So instead of calling
> foo, I think you can use objcopy to call bar instead.
> 
> To avoid the case of Rust core refering to symbols typically provided
> by the --rtlib={libgcc|compiler-rt}, what if we:
> 1. build core.o (with reference to the unfavorable symbols)
> 2. use objcopy to rename references in core.o to the symbols listed in
> this file; maybe prepend them with `rust_core_` or something.
> 3. provide this crate with panic'ing definitions, but for the renamed
> symbols.
> 
> That way, enabling CONFIG_RUST=y won't hide the case where C code is
> triggering such libcalls from the C compiler?
> 
> To restate the concern, I don't want CONFIG_RUST=y to hide that fact
> that someone wrote `float x, y; if (x != y) ...` in C code, where the
> C compiler will likely lower that to a libcall to __nesf2 since with
> the current approach in this patch, linkage would proceed. The current
> behavior is to intentionally fail to link.  I think what I describe
> above may work to keep this intended behavior of the kernel's build
> system.
> 
> Ah, looks like there's objcopy flags:
>        --redefine-sym old=new
>            Change the name of a symbol old, to new.  This can be
> useful when one is trying link
>            two things together for which you have no source, and there
> are name collisions.
> 
>        --redefine-syms=filename
>            Apply --redefine-sym to each symbol pair "old new" listed
> in the file filename.
>            filename is simply a flat file, with one symbol pair per
> line.  Line comments may be
>            introduced by the hash character.  This option may be given
> more than once.
> 
> So probably could start with my diff from above, but use
> --redefine-syms=filename instead of --strip-symbols=.
> 
> --
> Thanks,
> ~Nick Desaulniers

This is the approach we are about to take, see
https://github.com/Rust-for-Linux/linux/pull/779.

It's easy for just one symbol that is known to be not defined, but it
can be more complex as some of these symbols can be defined on a
platform but not another, so we would have to generate a dynamic list
of what symbols to "hijack" depending on the config. Currently we
avoid this issue by having all symbols in compiler_builtins
crate weak, but we couldn't weakly redefine a symbol.

It's certainly doable, though, but it require some effort. I am
not quite available recently so hadn't further extend and polish my
patch.

Best,
Gary

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ