[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202208171653.6BAB91F35@keescook>
Date: Wed, 17 Aug 2022 16:56:02 -0700
From: Kees Cook <keescook@...omium.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
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,
linux-fsdevel@...r.kernel.org, patches@...ts.linux.dev,
Jarkko Sakkinen <jarkko@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Geoffrey Thomas <geofft@...reload.com>,
Wedson Almeida Filho <wedsonaf@...gle.com>,
Sven Van Asbroeck <thesven73@...il.com>,
Gary Guo <gary@...yguo.net>, Boqun Feng <boqun.feng@...il.com>,
Maciej Falkowski <m.falkowski@...sung.com>,
Wei Liu <wei.liu@...nel.org>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>
Subject: Re: [PATCH v9 06/27] rust: add C helpers
On Wed, Aug 17, 2022 at 11:44:53PM +0200, Miguel Ojeda wrote:
> On Wed, Aug 17, 2022 at 10:34 PM Kees Cook <keescook@...omium.org> wrote:
> >
> > Gotcha -- it's for the implicit situations (e.g. -C overflow-checks=on),
>
> Yeah, exactly.
>
> > nothing is expected to explicitly call the Rust panic handler?
>
> If by explicitly you mean calling `panic!()`, then in the `kernel`
> crate in the v9 patches there is none.
Perfect. It may be worth stating this explicitly with the helper. i.e.
"This is for handling any panic!() calls in core Rust, but should not
ever be used in the 'kernel' create; failures should be handled."
> Though we may want to call it in the future (we have 4 instances in
> the full code not submitted here, e.g. for mismatching an independent
> lock guard with its owner). They can be avoided depending on how we
> want the design to be and, I guess, what the "Rust panic" policy will
> finally be (i.e. `BUG()` or something softer).
>
> Outside the `kernel` crate, there are also instances in proc macros
> and Rust hostprogs/scripts (compilation-time in the host), in the
> `alloc` crate (compiled-out) and in the `compiler_builtins` crate (for
> e.g. `u128` support that eventually we would like to not see
> compiled-in).
Sounds good!
-Kees
--
Kees Cook
Powered by blists - more mailing lists