linux-kernel - Re: [PATCH v8 02/14] rust: hrtimer: introduce hrtimer support

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: <CAJ-ks9=f45WJKFwB4J0_a4j_Urf=yR_wukmfhRwRqtczDXfSPg@mail.gmail.com>
Date: Fri, 21 Feb 2025 14:46:07 -0500
From: Tamir Duberstein <tamird@...il.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Andreas Hindborg <a.hindborg@...nel.org>, Miguel Ojeda <ojeda@...nel.org>, 
	Anna-Maria Behnsen <anna-maria@...utronix.de>, Frederic Weisbecker <frederic@...nel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Danilo Krummrich <dakr@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Alice Ryhl <aliceryhl@...gle.com>, 
	Trevor Gross <tmgross@...ch.edu>, Lyude Paul <lyude@...hat.com>, Guangbo Cui <2407018371@...com>, 
	Dirk Behme <dirk.behme@...il.com>, Daniel Almeida <daniel.almeida@...labora.com>, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 02/14] rust: hrtimer: introduce hrtimer support

On Fri, Feb 21, 2025 at 10:19 AM Boqun Feng <boqun.feng@...il.com> wrote:
>
> On Fri, Feb 21, 2025 at 09:46:08AM -0500, Tamir Duberstein wrote:
> > On Fri, Feb 21, 2025 at 9:40 AM Boqun Feng <boqun.feng@...il.com> wrote:
> > >
> > > Hmm... if you mean:
> > >
> > > trait HasHrTimer {
> > >     unsafe fn start(&self, expires: Ktime) {
> > >         ...
> > >     }
> > > }
> > >
> > > Then it'll be problematic because the pointer derived from `&self`
> > > doesn't have write provenance, therefore in a timer callback, the
> > > pointer cannot be used for write, which means for example you cannot
> > > convert the pointer back into a `Pin<Box<HasTimer>>`.
> > >
> > > To answer Tamir's question, pointers are heavily used here because we
> > > need to preserve the provenance.
> >
> > Wouldn't the natural implication be that &mut self is needed? Maybe
>
> For an `Arc<HasTimer>`, you cannot get `&mut self`.
>
> > you can help me understand why pointers can express a contract that
> > references can't?
>
> I assume you already know what a pointer provenance is?
>
>         http://doc.rust-lang.org/std/ptr/index.html#provenance
>
> Passing a pointer (including offset operation on it) preserves the
> provenance (determined as derive time), however, deriving a pointer from
> a reference gives the pointer a provenance based on the reference type.
> For example, let's say we have an `Arc<i32>` and a clone:
>
>         let arc = Arc::new(42);
>         let clone = arc.clone();
>
> you can obviously do a into_raw() + from_raw() pair:
>
>         let ptr = Arc::into_raw(arc);
>         let arc = unsafe { Arc::from_raw(arc) };
>
> however, if you create a reference based on `Arc::into_raw()`, and then
> derive a pointer from that, you change the provenance, therefore the
> below code would generate UB:
>
>         // cannot mutably borrow because of clone.
>         let ptr = unsafe { &*Arc::into_raw(arc) } as *const i32;
>
>         let arc = unsafe { Arc::from_raw(ptr) };
>
>
> (playground code snippet for this example)
>
>         https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=15e051db46c3886b29ed02e579562278
>
> As you already know, the whole thing about pointers/references here is
> passing the value to the callback and the callback can "reconstruct" the
> data, in such a case, reborrowing in the middle of the chain into a
> reference is not necessary, and as the above shows, it can be
> problematic.
>
> Hope this could be helpful.
>
> Regards,
> Boqun

Thanks for the explanation. I think where I'm still confused is that
provenance is to pointers as the type system is to references. In
other words, it's not clear to me how using pointers solves the
problem of wanting to write through an Arc. Is the idea that the
pointer inside the Arc has write provenance, and that by doing pointer
offsets instead of going through references we get to break rules
about mutability?