linux-kernel - Re: [PATCH v2 1/2] rust: sync: add `ArcBorrow::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: <4aef25d7-5135-4444-a461-fdef02f969e0@proton.me>
Date: Mon, 11 Mar 2024 15:04:27 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida Filho <wedsonaf@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, Andreas Hindborg <a.hindborg@...sung.com>, rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] rust: sync: add `ArcBorrow::from_raw`

On 3/11/24 09:58, Alice Ryhl wrote:
> On Sat, Mar 9, 2024 at 1:56 PM Benno Lossin <benno.lossin@...ton.me> wrote:
>>> +    /// Creates an [`ArcBorrow`] to an [`Arc`] that has previously been deconstructed with
>>> +    /// [`Arc::into_raw`].
>>> +    ///
>>> +    /// # Safety
>>> +    ///
>>> +    /// * The provided pointer must originate from a call to [`Arc::into_raw`].
>>> +    /// * For the duration of the lifetime annotated on this `ArcBorrow`, the reference count must
>>> +    ///   not hit zero.
>>> +    /// * For the duration of the lifetime annotated on this `ArcBorrow`, there must not be a
>>> +    ///   [`UniqueArc`] reference to this value.
>>
>> I am a bit confused, this feels to me like it should be guaranteed by
>> `UniqueArc` and not by this function. Currently there is not even a way
>> of getting a `*const T` from a `UniqueArc`.
>> So I think we can remove this requirement and instead have the
>> requirement for creating `UniqueArc` that not only the refcount is
>> exactly 1, but also that no `ArcBorrow` exists.
> 
> If you combine this with `into_unique_or_drop` that is introduced in
> the next patch of this series, then you could perform these
> operations:
> 
> * Arc::into_raw
> * ArcBorrow::from_raw
> * Arc::from_raw
> * Arc::into_unique_or_drop
> * And then use the ArcBorrow
> 
> If we drop the final safety requirement from `ArcBorrow::from_raw`,
> then the above would be allowed. The refcount does not hit zero at any
> point during these operations. The only unsafe functions are
> Arc::into_raw, Arc::from_raw, and ArcBorrow::from_raw, so this safety
> requirement must go on one of them. It seems to me that, out of these,
> ArcBorrow::from_raw is the most appropriate choice.
> 
> Thoughts?

I see, it is a bit unfortunate that we have to put the constraint onto
`ArcBorrow::from_raw`, but I also do not see a better place. Thus:

Reviewed-by: Benno Lossin <benno.lossin@...ton.me>

-- 
Cheers,
Benno