rust/kernel/miscdevice.rs | 8 ++++++++ 1 file changed, 8 insertions(+)
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>
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
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,
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> >
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 :)
© 2016 - 2025 Red Hat, Inc.