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: <CAH5fLgjz7nd2DfqKJfDKFpODJ_TUMP1omN+7DqTnpqTNrXTC6g@mail.gmail.com>
Date: Thu, 21 Nov 2024 11:08:05 +0100
From: Alice Ryhl <aliceryhl@...gle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Matthew Wilcox <willy@...radead.org>, 
	Vlastimil Babka <vbabka@...e.cz>, John Hubbard <jhubbard@...dia.com>, 
	"Liam R. Howlett" <Liam.Howlett@...cle.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Arnd Bergmann <arnd@...db.de>, 
	Christian Brauner <brauner@...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>, linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	rust-for-linux@...r.kernel.org, Andreas Hindborg <a.hindborg@...nel.org>
Subject: Re: [PATCH v8 7/7] rust: miscdevice: add mmap support

On Wed, Nov 20, 2024 at 9:07 PM Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
>
> On Wed, Nov 20, 2024 at 02:50:01PM +0000, Alice Ryhl wrote:
> > Using the vma support introduced by the previous commit, introduce mmap
> > support for miscdevices. The mmap call is given a vma that is undergoing
> > initial setup, so the VmAreaNew type is used.
>
> Again, I'd be explicit about the VMA being passed to a struct
> file_operations->mmap() hook on mmap. Otherwise this seems super vague to
> me!

I wasn't sure if vmas could be constructed in any context other than
mmap. Will reword.

> > Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
> > ---
> >  rust/kernel/miscdevice.rs | 28 ++++++++++++++++++++++++++++
> >  1 file changed, 28 insertions(+)
> >
> > diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs
> > index 7e2a79b3ae26..4e4b9476e092 100644
> > --- a/rust/kernel/miscdevice.rs
> > +++ b/rust/kernel/miscdevice.rs
> > @@ -11,6 +11,7 @@
> >  use crate::{
> >      bindings,
> >      error::{to_result, Error, Result, VTABLE_DEFAULT_ERROR},
> > +    mm::virt::VmAreaNew,
> >      prelude::*,
> >      str::CStr,
> >      types::{ForeignOwnable, Opaque},
> > @@ -110,6 +111,11 @@ fn release(device: Self::Ptr) {
> >          drop(device);
> >      }
> >
> > +    /// Handle for mmap.
> > +    fn mmap(_device: <Self::Ptr as ForeignOwnable>::Borrowed<'_>, _vma: &VmAreaNew) -> Result {
>
> You will have to help me with this :) ForeignOwnable, Borrowed<'_>, _vma I'm a
> bit lost here!

When you implement the Miscdevice for your own type, you write a block
like this one:

impl Miscdevice for MyType {
    type Ptr = Arc<MyType>;
    ...
}

Here Arc is a pointer type (very similar to ARef) that represents
ownership over a refcount to a refcounted value.

In this case:
* Self refers to MyType.
* Self::Ptr refers to Arc<MyType>
* <Self::Ptr as ForeignOwnable>::Borrowed<'_> refers to ArcBorrow<MyType>

The last step is resolved to ArcBorrow<MyType> because of this impl
block in rust/kernel/sync/arc.rs:

impl<T: 'static> ForeignOwnable for Arc<T> {
    type Borrowed<'a> = ArcBorrow<'a, T>;
    ...
}

Note that Self::Ptr is short-hand for <Self as Miscdevice>::Ptr.

> > +        kernel::build_error(VTABLE_DEFAULT_ERROR)
>
> What is this? Is this not yet implemented or something, and this is a
> placeholder or something?

It's a build-time assertion that this function is dead-code eliminated.

There are two cases:
* Either the driver does not override mmap. In this case, we store a
null pointer in the fops table.
* Or the driver overrides mmap with their own implementation. In this
case, we store a function pointer to whichever implementation they
provided.
In neither case is the above function present anywhere in the final executable.

Alice

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ