linux-kernel - Re: [PATCH v3] rust: kernel: introduce `unsafe_precondition

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: <aIzF1dMtIVXN0pDj@fedora>
Date: Fri, 1 Aug 2025 19:19:09 +0530
From: Ritvik Gupta <ritvikfoss@...il.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: 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>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>, skhan@...uxfoundation.org,
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v3] rust: kernel: introduce `unsafe_precondition_assert!`
 macro

On Thu, Jul 31, 2025 at 01:42:42PM +0200, Miguel Ojeda wrote:
> On Thu, Jul 31, 2025 at 1:12 PM Ritvik Gupta <ritvikfoss@...il.com> wrote:
> >
> > +/// /// - `buf` must be non-null.
> > +/// /// - `buf` must be 16-byte aligned.
> 
> We don't know since the full body is not shown, but it is likely this
> would need to also be a valid pointer, i.e. it may be an uncommon
> example.

I believe this is a valid use-case for `unsafe_precondition_assert!`.
Should we add similar example?

```cpu.rs
/// Creates a new [`CpuId`] from the given `id` without checking bounds.
///
/// # Safety
///
/// The caller must ensure that `id` is a valid CPU ID (i.e., `0 <= id < nr_cpu_ids()`).
#[inline]
pub unsafe fn from_u32_unchecked(id: u32) -> Self {
    debug_assert!(id < nr_cpu_ids());

    // Ensure the `id` fits in an [`i32`] as it's also representable that way.
    debug_assert!(id <= i32::MAX as u32);

    // INVARIANT: The function safety guarantees `id` is a valid CPU id.
    Self(id)
}
```

> More importantly, could we have a user of the macro introduced in a
> second patch so that it gets already used?

I believe the `debug_assert!` calls inside the `unsafe fn`
(excluding 'const fn' and 'CONFIG_RUST_OVERFLOW_CHECKS' flag) 
are the intended targets for `unsafe_precondition_assert!`.

A quick grep (`git grep -B 15 -A 10 "debug_assert"`),
I could find 6 relevant callers in `alloc/kvec.rs` (2) and `cpu.rs` (4),
unless I'm missing something.

I'll send another patch for this, after getting the example correct.
Thanks for the feedback :)