linux-kernel - Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

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: <e14cfb34-308f-4797-afe7-4e7e2d470fe3@app.fastmail.com>
Date: Fri, 31 Jan 2025 20:37:41 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Christian Schrefl" <chrisi.schrefl@...il.com>,
 "Andrew Lunn" <andrew@...n.ch>, "Miguel Ojeda" <ojeda@...nel.org>
Cc: "Alex Gaynor" <alex.gaynor@...il.com>,
 "Boqun Feng" <boqun.feng@...il.com>, "Gary Guo" <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 "Benno Lossin" <benno.lossin@...ton.me>,
 "Andreas Hindborg" <a.hindborg@...nel.org>,
 "Alice Ryhl" <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>,
 "Jonathan Corbet" <corbet@....net>, "Russell King" <linux@...linux.org.uk>,
 "Rudraksha Gupta" <guptarud@...il.com>, "Ard Biesheuvel" <ardb@...nel.org>,
 "Geert Stappers" <stappers@...ppers.nl>,
 "Jamie Cunliffe" <Jamie.Cunliffe@....com>,
 "Sven Van Asbroeck" <thesven73@...il.com>, rust-for-linux@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

On Fri, Jan 31, 2025, at 19:58, Christian Schrefl wrote:
> On 31.01.25 5:05 PM, Andrew Lunn wrote:
>>> To fix this Rust would have to provide a way to build the core
>>> library without float support. I don't know if there is a plan
>>> already to allow this.
>> 
>> Floating point is banned within the kernel, except for in very narrow
>> conditions, because the floating point registers are lazy saved on
>> context switch. If the kernel uses the floating point registers, you
>> can break user space in bad ways.
>> 
>> I expect this has been discussed, since it is well known kernel
>> restriction. Maybe go see what happened to that discussion within RfL?
>
> After checking again, it seems the float intrinsics are actually not
> needed anymore at least for my config.

Ah, nice! If this is true for all architectures using the current
rust compiler, it would be great to remove the FP stubs entirely
and have link errors instead of panicking, to make it consistent
with C.

> Only `__aeabi_uldivmod` is still
> required for `parse_u64_into` since [0] allows disabling float formatting.
>
> Link error without the `__aeabi_uldivmod` symbol defined:
>
> ld.lld: error: undefined symbol: __aeabi_uldivmod
>>>> referenced by num.rs:580 (/home/chrisi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:580)
>>>>               rust/core.o:(core::fmt::num::parse_u64_into::<39>) in archive vmlinux.a
>>>> referenced by num.rs:589 (/home/chrisi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:589)
>>>>               rust/core.o:(core::fmt::num::parse_u64_into::<39>) in archive vmlinux.a
>>>> referenced by num.rs:589 (/home/chrisi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:589)
>>>>               rust/core.o:(core::fmt::num::parse_u64_into::<39>) in archive vmlinux.a
>>>> referenced 34 more times
>>>> did you mean: __aeabi_uidivmod
>>>> defined in: vmlinux.a(arch/arm/lib/lib1funcs.o)
>
> Not sure if we should just implement `__aeabi_uldivmod`, keep the 
> panicking intrinsic for it or somehow fix it in upstream Rust?

The 64-bit division is particularly easy to introduce by accident
on 32-bit architectures, so ending up in a panic here is clearly
a problem. From the message above it appears that there is only 
a single calling function (parse_u64_into()) in the rust library,
so I wonder if it might be sufficient to split that out into
another object file that then doesn't need to get linked into
the kernel, or for the kernel to override it with an implementation
that does not rely on __aeabi_uldivmod() but calls __do_div64()
instead.

Since parse_u64_into seems to be a parsing function that is
expected to be slow, it should be acceptable to call __do_div64()
here, while we still prevent calling __aeabi_uldivmod() from
kernel source code.

Note that on earlier ARMv7 (Cortex-A8, A9), even a 32-bit
division is implemented through an expensive software loop.
Later cores (Cortex-A7, A15, A17) have native 32-bit division
instructions but still no 64-bit ones.

       Arnd