linux-kernel - Re: [PATCH] lsm: rust: mark SecurityCtx methods inline

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

Message-ID: <CANiq72=SZv7UPvcZ1NgBtbM72n42b8GqS+rTVjccVZmn4z3SVg@mail.gmail.com>
Date: Wed, 5 Mar 2025 00:16:25 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Paul Moore <paul@...l-moore.com>
Cc: Alice Ryhl <aliceryhl@...gle.com>, James Morris <jmorris@...ei.org>, 
	"Serge E. Hallyn" <serge@...lyn.com>, Miguel Ojeda <ojeda@...nel.org>, 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>, 
	Trevor Gross <tmgross@...ch.edu>, rust-for-linux@...r.kernel.org, 
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lsm: rust: mark SecurityCtx methods inline

On Tue, Mar 4, 2025 at 10:57 PM Paul Moore <paul@...l-moore.com> wrote:
>
> Thanks.  Yes, I've seen the summary and the recent threads around Rust
> in the Linux kernel.  I don't want to drag all of that up here, but I
> will simply say that from the perspective of the LSM framework we're
> happy to work with the Rust devs to ensure that the LSM framework is
> well supported with Rust bindings.  However, I will add that my own
> Rust related efforts are going to be very limited as my understanding
> of Rust is still frustratingly low; until that improves I'll be
> reliant on others like Alice and you to submit patches for
> discussion/acceptance when there are issues.  Thankfully that has
> proven to work fairly well over the past few months and I would like
> to see that continue.
>
> As far as the mechanics of which tree to merge code, I'll probably
> continue to ask in most cases simply so we are all clear on where the
> patches will land and how they get up to Linus.  From my perspective
> there is no harm in asking, and I *really* want to encourage
> cross-subsystem communication as much as I can; I've been seeing an
> increasing trend towards compartmentalization across subsystems and I
> believe the best way to push back against that is to talk a bit more,
> even if it is just a mundane "my tree or yours?".

Definitely agreed on talking more and encouraging more communication,
so if deciding based on a case-by-case is best for you, I think that
is good.

And thanks for helping us here in whatever way you can!

Cheers,
Miguel