linux-kernel - Re: [PATCH v2 2/2] rust: arc: remove `ArcBorrow` in favour of `WithRef`

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]

Date:   Mon, 25 Sep 2023 15:04:25 +0000
From:   Alice Ryhl <aliceryhl@...gle.com>
To:     benno.lossin@...ton.me
Cc:     a.hindborg@...sung.com, alex.gaynor@...il.com,
        aliceryhl@...gle.com, bjorn3_gh@...tonmail.com,
        boqun.feng@...il.com, gary@...yguo.net,
        linux-kernel@...r.kernel.org, ojeda@...nel.org,
        rust-for-linux@...r.kernel.org, walmeida@...rosoft.com,
        wedsonaf@...il.com
Subject: Re: [PATCH v2 2/2] rust: arc: remove `ArcBorrow` in favour of `WithRef`

>> I'm concerned about this change, because an `&WithRef<T>` only has
>> immutable permissions for the allocation. No pointer derived from it
>> may be used to modify the value in the Arc, however, the drop
>> implementation of Arc will do exactly that. 
> 
> That is indeed a problem. We could put the value in an `UnsafeCell`, but
> that would lose us niche optimizations and probably also other optimizations.

This is an option. Niche optimizations don't matter for `WithRef` since
it's never directly wrapped with `Option`.

> > It also means that we
> > can't convert an Arc with refcount 1 into a UniqueArc.
> 
> I think you still can, since to do that you would consume the `Arc<T>` by
> value, thus guaranteeing that no references (and thus no `&WithRef<T>`) exist.
> So I think this would still be fine.

The problem is that if you have an `&WithRef<T>` and use that to create
an `Arc<T>`, then the raw pointer in the `Arc<T>` was created from an
immutable reference, so the same restrictions apply to that `Arc<T>`.
And if you convert it into an `UniqueArc<T>`, then the same restrictions
also apply to the `UniqueArc<T>` because it's raw pointer was derived
from the immutable reference.

Alice