[PATCH] rust: miscdevice: Export vtable testing

[PATCH] rust: miscdevice: Export vtable testing

[Matthew Maurer]

A common pattern in the kernel is to test whether a file belongs to a
particular driver by checking its `f_op` struct against an expected
value. This provides a safe way to perform that test for `MiscDevice`
implementations without needing to directly expose the vtable.

Signed-off-by: Matthew Maurer <mmaurer@google.com>
---
 rust/kernel/miscdevice.rs | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs
index 939278bc7b03489a647b697012e09223871c90cd..5f59eda57c38be5f0d54fa9692fe5b2819e31480 100644
--- a/rust/kernel/miscdevice.rs
+++ b/rust/kernel/miscdevice.rs
@@ -177,6 +177,14 @@ fn show_fdinfo(
     }
 }
 
+/// Determines whether a given `File` is backed by the `T` `MiscDevice` based on vtable matching.
+pub fn is_miscdevice_file<T: MiscDevice>(file: &File) -> bool {
+    let vtable = core::ptr::from_ref(&MiscdeviceVTable::<T>::VTABLE);
+    // SAFETY: `f_op` is not mutated after file creation
+    let file_vtable = unsafe { (*file.as_ptr()).f_op };
+    vtable == file_vtable
+}
+
 /// A vtable for the file operations of a Rust miscdevice.
 struct MiscdeviceVTable<T: MiscDevice>(PhantomData<T>);
 

---
base-commit: 86731a2a651e58953fc949573895f2fa6d456841
change-id: 20250627-linux-miscident-7b67db234a5c

Best regards,
-- 
Matthew Maurer <mmaurer@google.com>

Re: [PATCH] rust: miscdevice: Export vtable testing

[Matthew Maurer]

On Fri, Jun 27, 2025 at 4:42 PM Matthew Maurer <mmaurer@google.com> wrote:
>
> A common pattern in the kernel is to test whether a file belongs to a
> particular driver by checking its `f_op` struct against an expected
> value. This provides a safe way to perform that test for `MiscDevice`
> implementations without needing to directly expose the vtable.
>
> Signed-off-by: Matthew Maurer <mmaurer@google.com>

Additionally, we have a sample user[1] of this in the Android ashmem
wrapper. They're currently working around it by grabbing the vtable
out of the registration and testing manually.

[1]: https://android-review.git.corp.google.com/c/kernel/common/+/3477511

> ---
>  rust/kernel/miscdevice.rs | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs
> index 939278bc7b03489a647b697012e09223871c90cd..5f59eda57c38be5f0d54fa9692fe5b2819e31480 100644
> --- a/rust/kernel/miscdevice.rs
> +++ b/rust/kernel/miscdevice.rs
> @@ -177,6 +177,14 @@ fn show_fdinfo(
>      }
>  }
>
> +/// Determines whether a given `File` is backed by the `T` `MiscDevice` based on vtable matching.
> +pub fn is_miscdevice_file<T: MiscDevice>(file: &File) -> bool {
> +    let vtable = core::ptr::from_ref(&MiscdeviceVTable::<T>::VTABLE);
> +    // SAFETY: `f_op` is not mutated after file creation
> +    let file_vtable = unsafe { (*file.as_ptr()).f_op };
> +    vtable == file_vtable
> +}
> +
>  /// A vtable for the file operations of a Rust miscdevice.
>  struct MiscdeviceVTable<T: MiscDevice>(PhantomData<T>);
>
>
> ---
> base-commit: 86731a2a651e58953fc949573895f2fa6d456841
> change-id: 20250627-linux-miscident-7b67db234a5c
>
> Best regards,
> --
> Matthew Maurer <mmaurer@google.com>
>

Re: [PATCH] rust: miscdevice: Export vtable testing

[Greg KH]

On Fri, Jun 27, 2025 at 04:46:04PM -0700, Matthew Maurer wrote:
> On Fri, Jun 27, 2025 at 4:42 PM Matthew Maurer <mmaurer@google.com> wrote:
> >
> > A common pattern in the kernel is to test whether a file belongs to a
> > particular driver by checking its `f_op` struct against an expected
> > value. This provides a safe way to perform that test for `MiscDevice`
> > implementations without needing to directly expose the vtable.
> >
> > Signed-off-by: Matthew Maurer <mmaurer@google.com>
> 
> Additionally, we have a sample user[1] of this in the Android ashmem
> wrapper. They're currently working around it by grabbing the vtable
> out of the registration and testing manually.
> 
> [1]: https://android-review.git.corp.google.com/c/kernel/common/+/3477511

As ashmem isn't going to be upstream, it's hard for us to treat this as
a real user :)

Re: [PATCH] rust: miscdevice: Export vtable testing

[Benno Lossin]

On Sat Jun 28, 2025 at 1:42 AM CEST, Matthew Maurer wrote:
> A common pattern in the kernel is to test whether a file belongs to a
> particular driver by checking its `f_op` struct against an expected
> value. This provides a safe way to perform that test for `MiscDevice`
> implementations without needing to directly expose the vtable.
>
> Signed-off-by: Matthew Maurer <mmaurer@google.com>
> ---
>  rust/kernel/miscdevice.rs | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/rust/kernel/miscdevice.rs b/rust/kernel/miscdevice.rs
> index 939278bc7b03489a647b697012e09223871c90cd..5f59eda57c38be5f0d54fa9692fe5b2819e31480 100644
> --- a/rust/kernel/miscdevice.rs
> +++ b/rust/kernel/miscdevice.rs
> @@ -177,6 +177,14 @@ fn show_fdinfo(
>      }
>  }
>  
> +/// Determines whether a given `File` is backed by the `T` `MiscDevice` based on vtable matching.
> +pub fn is_miscdevice_file<T: MiscDevice>(file: &File) -> bool {
> +    let vtable = core::ptr::from_ref(&MiscdeviceVTable::<T>::VTABLE);

I don't think this always returns the same pointer. So this function
might return false in a case where `T` actually backs `file`...

---
Cheers,
Benno

> +    // SAFETY: `f_op` is not mutated after file creation
> +    let file_vtable = unsafe { (*file.as_ptr()).f_op };
> +    vtable == file_vtable
> +}
> +
>  /// A vtable for the file operations of a Rust miscdevice.
>  struct MiscdeviceVTable<T: MiscDevice>(PhantomData<T>);
>  
>
> ---
> base-commit: 86731a2a651e58953fc949573895f2fa6d456841
> change-id: 20250627-linux-miscident-7b67db234a5c
>
> Best regards,

Re: [PATCH] rust: miscdevice: Export vtable testing

[Greg KH]

On Fri, Jun 27, 2025 at 11:42:38PM +0000, Matthew Maurer wrote:
> A common pattern in the kernel is to test whether a file belongs to a
> particular driver by checking its `f_op` struct against an expected
> value. This provides a safe way to perform that test for `MiscDevice`
> implementations without needing to directly expose the vtable.

Ick, who does that?  And why?  Who cares within the kernel what driver
owns a fd as why would any driver ever be passed a fd that is not owned
by it?

I would like to see a real user first please, or point out some places
in the kernel today that does this so we can go and fix them up :)

thanks,

greg k-h