linux-kernel - Re: [PATCH v3] rust: regulator: add a bare minimum regulator abstraction

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DA04ZK6NFF1N.35LFZRY7O7SG8@kernel.org>
Date: Mon, 19 May 2025 14:30:05 +0200
From: "Benno Lossin" <lossin@...nel.org>
To: "Mark Brown" <broonie@...nel.org>
Cc: "Alexandre Courbot" <acourbot@...dia.com>, "Daniel Almeida"
 <daniel.almeida@...labora.com>, "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>, "Danilo
 Krummrich" <dakr@...nel.org>, "Boris Brezillon"
 <boris.brezillon@...labora.com>, "Sebastian Reichel"
 <sebastian.reichel@...labora.com>, "Liam Girdwood" <lgirdwood@...il.com>,
 <linux-kernel@...r.kernel.org>, <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH v3] rust: regulator: add a bare minimum regulator
 abstraction

On Mon May 19, 2025 at 1:46 PM CEST, Mark Brown wrote:
> On Mon, May 19, 2025 at 01:25:56PM +0200, Benno Lossin wrote:
>> On Mon May 19, 2025 at 11:56 AM CEST, Mark Brown wrote:
>
>> > No.  You should not leak any refcount, the per consumer refcount
>> > duplicates what's being done for the regulator as a whole, one should
>> > never be incremented or decremented without the other (but there may be
>> > multiple consumers to choose from).
>
>> What stops the last `regulator_put` to also call `regulator_disable` a
>> correct number of times?
>
> We obviously could but the regulator API defaults to not doing anything
> unless explicitly told to since getting things wrong can physically
> damage the system.  We've no idea if just disabling the regulator would
> be safe at this point so we just don't touch anything and complain about
> it.

Gotcha.

>> What are the kinds of problems that one could encounter when not calling
>> `regulator_disable` before `regulator_put` or if `regulator_enable` was
>> never called to begin with?
>
> If you don't disable the regulator you've just leaked a reference which
> is obviously a problem.

For sure. But I'm trying to figure out if this is a safety-related issue
or not. Safety in Rust has a rather specific meaning that can be
summarized with "no UB". So since the C side does nothing if the user
screwed up the refcounts, it lets me to believe that we don't have any
safety related issues when forgetting to call `regulator_disable`.

Of course we still should strive for an API that makes that impossible
or at least very hard, but we don't need to make the API `unsafe` or
have to take special care. (At least if I understood correctly)

---
Cheers,
Benno