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-next>] [day] [month] [year] [list]

Message-ID: <D90J8JOGEBWI.4P0BAZG2R4G7@proton.me>
Date: Mon, 07 Apr 2025 16:04:14 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Manish Shakya <msh.shakya@...il.com>, chrisi.schrefl@...il.com, Jamie.Cunliffe@....com, a.hindborg@...nel.org, alex.gaynor@...il.com, aliceryhl@...gle.com, andrew@...n.ch, ardb@...nel.org, bjorn3_gh@...tonmail.com, boqun.feng@...il.com, corbet@....net, gary@...yguo.net, guptarud@...il.com, linus.walleij@...aro.org, linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, linux@...linux.org.uk, ojeda@...nel.org, rust-for-linux@...r.kernel.org, stappers@...ppers.nl, thesven73@...il.com, tmgross@...ch.edu
Subject: Re: [PATCH v3] arm: rust: Enable Rust support for ARMv7

On Sun Apr 6, 2025 at 11:31 PM CEST, Miguel Ojeda wrote:
> On Sun, Apr 6, 2025 at 11:17 PM Benno Lossin <benno.lossin@...ton.me> wrote:
>>
>> Maybe we should rename it to something more discouraging then. Eg
>> CONFIG_RUST_BUILD_ASSERT_DISABLE.
>
> To clarify: it doesn't disable them, but rather converts them to runtime checks.

Yeah I checked what it does before. I still think that we should
consider this as disabling the build asserts.

> Perhaps it should be _ESCAPE_HATCH or _KEEP_DISABLED or _AT_RUNTIME or
> similar -- though changing it now may be even more confusing.

I don't understand what _KEEP_DISABLED would mean. For me, _DISABLE
sounds much more "threatening" than the other options.

Maybe we should also hide it behind CONFIG_EXPERT?

> The description already mentions it should not happen, and that is an
> escape hatch, and the recommendation and the default is N. So if
> someone enables it in production, they really went out of their way to
> do so, and even then they are protected by the panics (that they
> shouldn't hit at all).

I suspect that most of the people sadly don't read the description.

> Eventually, we may just want to remove it entirely if we never see a
> case failing and/or if we get proper support for those from upstream
> Rust for this.

Yeah, the upstream support would be the best. Did we ever need to enable
this option?

---
Cheers,
Benno