linux-kernel - Re: [PATCH v7 06/25] 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]

Date:   Wed, 25 May 2022 14:29:51 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Gary Guo <gary@...yguo.net>
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,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Wedson Almeida Filho <wedsonaf@...gle.com>,
        Sven Van Asbroeck <thesven73@...il.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Arnd Bergmann <arnd@...nel.org>
Subject: Re: [PATCH v7 06/25] rust: add `compiler_builtins` crate

 On Mon, May 23, 2022 at 4:42 PM Gary Guo <gary@...yguo.net> wrote:
>
> On Mon, 23 May 2022 11:37:16 -0700
> Nick Desaulniers <ndesaulniers@...gle.com> wrote:
>
> > Also, I'm not sure my concern about explicit build failures for C code
> > was ever addressed?  We have a constant problem with `long long`
> > division on ARCH=arm32 and ARCH=i386 in C code.
> > https://lore.kernel.org/lkml/CAKwvOdk+A2PBdjSFVUhj4xyCGCKujtej1uPgywQgrKPiK2ksPw@mail.gmail.com/
> >
> > > +#[cfg(target_arch = "arm")]
> > > +define_panicking_intrinsics!("`u64` division/modulo should not be
> > > used", {
> > > +    __aeabi_uldivmod,
> > > +    __mulodi4,
> > > +});
>
> Starting in LLVM 14 (used in Rust 1.60+), __mulodi4 will no longer be
> generated. So that can be removed.

I'm familiar, but good catch. ;)
https://reviews.llvm.org/D108936
https://reviews.llvm.org/D108842
https://reviews.llvm.org/D108844
https://reviews.llvm.org/D112750
https://reviews.llvm.org/D108928
https://reviews.llvm.org/D108939
https://bugs.llvm.org/show_bug.cgi?id=28629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103034

>
> As for __aeabi_uldivmod, is there any reason that it can't just be
> defined in arch/arm/lib? There are quite a few __aeabi functions already
> defined there.

Indeed.
arch/arm/kernel/armksyms.c and
arch/arm/lib/lib1funcs.S

This is the previous thread I recall w/ Linus:
https://lore.kernel.org/llvm/CAHk-=wiydA=Oay+NB2m2ewCHpPEcoU51qPFrzsekFoPu7QPtuw@mail.gmail.com/

If CONFIG_RUST provides those symbols, it will hide the linkage
failures that we try to use to spot & avoid 64b division that's open
coded using the / binary operator, rather than the kernel's do_div()
and friends.

>
> The source of __aeabi_uldivmod in compiler-rt seems quite simple, just
> delegating to __uldivmoddi4. I think just changing that to
> div64_u64_rem should do the job?

Maybe; send a patch and see what happens. There's probably other 32b
architectures that will need other symbols that also handle 64b
division though, so it's not as simple as providing __aeabi_uldivmod
for ARM.

There's probably someone from linux-arm-kernel that can provide
additional context.
https://lore.kernel.org/linux-arm-kernel/alpine.LFD.2.00.1104271305580.24613@xanadu.home/
is pretty old, but refers to policies that seem to pre-exist other
references to __aeabi_uldivmod on that list.

arch/nios2/kernel/nios2_ksyms.c exports __udivmoddi4, but it also
explicitly links against libgcc.  I'm guessing that's frowned upon,
but not out of the question relative to having the kernel ported to
the architecture at all.

>
> https://android.googlesource.com/toolchain/compiler-rt/+/release_32/lib/arm/aeabi_uldivmod.S

Here's the latest source.
https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/arm/aeabi_uldivmod.S
and __uldivmoddi4:
https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/udivmoddi4.c

By chance, does any of the rust code in this series use open coded
division w/ 64 bit operands (rather than using do_div) by accident?

I'm also curious about the panic message for 128b operands. IIUC,
those are functions that may have `long long` operands.  On 32b ARM,
which is ILP32, I'd have expected `long long` to be 64b, not 128b.
Message might be misleading.
-- 
Thanks,
~Nick Desaulniers