linux-kernel - Re: [PATCH v11 6/8] mm: rust: add VmAreaNew for f

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: <87o708e6w2.fsf@kernel.org>
Date: Wed, 15 Jan 2025 10:57:49 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Alice Ryhl" <aliceryhl@...gle.com>
Cc: "Miguel Ojeda" <ojeda@...nel.org>,  "Matthew Wilcox"
 <willy@...radead.org>,  "Lorenzo Stoakes" <lorenzo.stoakes@...cle.com>,
  "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>,  "Jann Horn"
 <jannh@...gle.com>,  "Suren Baghdasaryan" <surenb@...gle.com>,  "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>,
  "Trevor Gross" <tmgross@...ch.edu>,  <linux-kernel@...r.kernel.org>,
  <linux-mm@...ck.org>,  <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH v11 6/8] mm: rust: add VmAreaNew for f_ops->mmap()

"Alice Ryhl" <aliceryhl@...gle.com> writes:

> On Thu, Jan 9, 2025 at 9:19 AM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>
>> "Alice Ryhl" <aliceryhl@...gle.com> writes:
>>
>> > On Mon, Dec 16, 2024 at 3:51 PM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>> >>
>> >> "Alice Ryhl" <aliceryhl@...gle.com> writes:
>> >>
>> >> > This type will be used when setting up a new vma in an f_ops->mmap()
>> >> > hook. Using a separate type from VmAreaRef allows us to have a separate
>> >> > set of operations that you are only able to use during the mmap() hook.
>> >> > For example, the VM_MIXEDMAP flag must not be changed after the initial
>> >> > setup that happens during the f_ops->mmap() hook.
>> >> >
>> >> > To avoid setting invalid flag values, the methods for clearing
>> >> > VM_MAYWRITE and similar involve a check of VM_WRITE, and return an error
>> >> > if VM_WRITE is set. Trying to use `try_clear_maywrite` without checking
>> >> > the return value results in a compilation error because the `Result`
>> >> > type is marked #[must_use].
>> >> >
>> >> > For now, there's only a method for VM_MIXEDMAP and not VM_PFNMAP. When
>> >> > we add a VM_PFNMAP method, we will need some way to prevent you from
>> >> > setting both VM_MIXEDMAP and VM_PFNMAP on the same vma.
>> >> >
>> >> > Acked-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com> (for mm bits)
>> >> > Reviewed-by: Jann Horn <jannh@...gle.com>
>> >> > Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
>> >> > ---
>> >> >  rust/kernel/mm/virt.rs | 181 ++++++++++++++++++++++++++++++++++++++++++++++++-
>> >> >  1 file changed, 180 insertions(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/rust/kernel/mm/virt.rs b/rust/kernel/mm/virt.rs
>> >> > index 3a23854e14f4..6d9ba56d4f95 100644
>> >> > --- a/rust/kernel/mm/virt.rs
>> >> > +++ b/rust/kernel/mm/virt.rs
>> >> > @@ -6,7 +6,7 @@
>> >> >
>> >> >  use crate::{
>> >> >      bindings,
>> >> > -    error::{to_result, Result},
>> >> > +    error::{code::EINVAL, to_result, Result},
>> >> >      mm::MmWithUser,
>> >> >      page::Page,
>> >> >      types::Opaque,
>> >> > @@ -171,6 +171,185 @@ pub fn vm_insert_page(&self, address: usize, page: &Page) -> Result {
>> >> >      }
>> >> >  }
>> >> >
>> >> > +/// A builder for setting up a vma in an `f_ops->mmap()` hook.
>> >>
>> >> Reading this line, I would expect to be able to chain update methods as
>> >> in `Builder::new().prop_a().prop_b().build()`. Could/should this type
>> >> accommodate a proper builder pattern? Or is "builder" not the right word
>> >> to use here?
>> >
>> > You cannot create values of this type yourself. Only the C
>> > infrastructure can do so.
>> >
>> > What would you call it if not "builder"?
>>
>> It looks more like a newtype with a bunch of setters and getters. It
>> also does not have a method to instantiate (`build()` or similar). So
>> how about newtype?
>
> I don't think newtype is helpful. Ultimately, the f_ops->mmap() hook
> is a *constructor* for a VMA, and the VmAreaNew type represents a VMA
> whose constructor is currently running. The "method to instantiate" is
> called "return".
>
> fn mmap(new_vma: &VmAreaNew) -> Result {
>     // VMAs for this driver must not be mapped as executable
>     new_vma.try_clear_may_exec()?;
>
>     // we are done constructing the vma, so return
>     Ok(())
> }
>
> Alice

Right. Let's update the docs for the `mmap` hook then:

+    /// Handle for mmap.
+    fn mmap(
+        _device: <Self::Ptr as ForeignOwnable>::Borrowed<'_>,
+        _file: &File,
+        _vma: &VmAreaNew,
+    ) -> Result {
+        kernel::build_error!(VTABLE_DEFAULT_ERROR)
+    }
+

```
Handle for mmap.

This function is invoked when a user space process invokes the `mmap`
system call on `_file`. The function is a callback that is part of the
VMA initializer. The kernel will do initial setup of the VMA before
calling this function. The function can then interact with the VMA
initialization by calling methods of `_vma`. If the function does not
return an error, the kernel will complete intialization of the VMA
according to the properties of `_vma`.
```

But I still do not think "builder" is the right term. `VmAreaNew` is
more like a configuration object to pass initialization properties of
the VMA back to the kernel.

How about "configuration object"?


Best regards,
Andreas Hindborg