linux-kernel - Re: [PATCH V7 03/16] rust: cpu: Add from

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: <2025011537-shuffling-unpaved-121a@gregkh>
Date: Wed, 15 Jan 2025 08:54:09 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: "Rafael J. Wysocki" <rafael@...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>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	linux-pm@...r.kernel.org,
	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH V7 03/16] rust: cpu: Add from_cpu()

On Wed, Jan 15, 2025 at 12:50:50PM +0530, Viresh Kumar wrote:
> On 14-01-25, 19:44, Greg KH wrote:
> > > +pub fn from_cpu(cpu: u32) -> Result<&'static Device> {
> > > +    // SAFETY: The pointer returned by `get_cpu_device()`, if not `NULL`, is a valid pointer to
> > > +    // a `struct device` and is never freed by the C code.
> > 
> > I thought it was pointed out that it could be freed when a cpu was
> > hot-unplugged?  Or is that a different device in the cpu code?  We seem
> > to have 2 of them and it's not obvious which is which :(
> 
> I did reply [1] to that earlier. The CPU can get unregistered but the
> memory for the device is never freed (it is part of struct cpu). Some
> calls on the CPU device may fail later on (if called for an unregisted
> dev), but should never crash the kernel.

Ah, but that's not really something that SAFETY should override, right?

Yes, you know your implementation of this will stop using the pointer in
the hotplug callback before it goes away but that's not documented here.
And having the device "fail" afterward isn't really ok either as you are
relying on the driver core to always check for this and I'm not so sure
that it always does on all codepaths.

But, I'm ok with this for now, as you are just copying the bad C model
at the moment, but it really feels like a huge foot-gun waiting to go
off.  Any way to put some more documentation here as in "use this at
your own risk!"?

thanks,

greg k-h