linux-kernel - Re: [PATCH] rust: fix building firmware abstraction on 32bit arm

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: <CANiq72kc4gzfieD-FjuWfELRDXXD2vLgPv4wqk3nt4pjdPQ=qg@mail.gmail.com>
Date: Fri, 11 Apr 2025 16:15:32 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Christian Schrefl <chrisi.schrefl@...il.com>, Luis Chamberlain <mcgrof@...nel.org>, 
	Russ Weight <russ.weight@...ux.dev>, Danilo Krummrich <dakr@...nel.org>, Miguel Ojeda <ojeda@...nel.org>, 
	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>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, 
	Trevor Gross <tmgross@...ch.edu>, linux-kernel@...r.kernel.org, 
	rust-for-linux@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] rust: fix building firmware abstraction on 32bit arm

On Fri, Apr 11, 2025 at 2:46 PM Benno Lossin <benno.lossin@...ton.me> wrote:
>
> Ah I overlooked this, you should be using `kernel::ffi` (or
> `crate::ffi`) instead of `core`. (for `c_char` it doesn't matter, but we
> shouldn't be using `core::ffi`, since we have our own mappings).

In 6.6, C `char` changed to unsigned, but `core::ffi::c_char` is
signed (in x86_64 at least).

We should just never use `core::ffi` (except in `rust/ffi.rs`, of
course) -- I think we should just add the C types to the prelude
(which we discussed in the past) so that it is easy to avoid the
mistake (something like the patch attached as the end result, but
tested and across a kernel cycle or two) and mention it in the Coding
Guidelines. Thoughts?

I tried to use Clippy's `disallowed-types` too:

    disallowed-types = [
        { path = "core::ffi::c_void", reason = "the `kernel::ffi`
types should be used instead" },
        { path = "core::ffi::c_char", reason = "the `kernel::ffi`
types should be used instead" },
        { path = "core::ffi::c_schar", reason = "the `kernel::ffi`
types should be used instead" },
        { path = "core::ffi::c_uchar", reason = "the `kernel::ffi`
types should be used instead" },
        { path = "core::ffi::c_short", reason = "the `kernel::ffi`
types should be used instead" },
        { path = "core::ffi::c_ushort", reason = "the `kernel::ffi`
types should be used instead" },
        { path = "core::ffi::c_int", reason = "the `kernel::ffi` types
should be used instead" },
        { path = "core::ffi::c_uint", reason = "the `kernel::ffi`
types should be used instead" },
        { path = "core::ffi::c_long", reason = "the `kernel::ffi`
types should be used instead" },
        { path = "core::ffi::c_ulong", reason = "the `kernel::ffi`
types should be used instead" },
        { path = "core::ffi::c_longlong", reason = "the `kernel::ffi`
types should be used instead" },
        { path = "core::ffi::c_ulonglong", reason = "the `kernel::ffi`
types should be used instead" },
    ]

But it goes across aliases.

Cheers,
Miguel

View attachment "0001-rust-add-C-types-to-the-prelude.patch" of type "text/x-patch" (37794 bytes)