Re: [PATCH v2 0/2] Untrusted Data Abstraction

[Simona Vetter <simona.vetter@ffwll.ch>]

On Thu, Dec 05, 2024 at 10:06:19AM +0100, Greg KH wrote:
> On Wed, Sep 25, 2024 at 08:52:57PM +0000, Benno Lossin wrote:
> > Enable marking certain data as untrusted. For example data coming from
> > userspace, hardware or any other external data source.
> > 
> > This idea originates from a discussion with Greg at Kangrejos. As far as I
> > understand the rationale, it is to prevent accidentally reading untrusted data
> > and using it for *logic* within the kernel. For example reading the length from
> > the hardware and not validating that it isn't too big. This is a big source for
> > logic bugs that later turn into vulnerabilities.
> > 
> > The API introduced in this series is not a silver bullet, users are still able
> > to access the untrusted value (otherwise how would they be able to validate
> > it?). But it provides additional guardrails to remind users that they ought to
> > validate the value before using it.
> > 
> > There are still some things to iron out on the Rust side:
> > - allow better handling of `Untrusted<T>`, for example allow comparing
> >   `Untrusted<[u8]>` for equality (we should do this via a trait extending
> >   `PartialEq`)
> > - rebase this on Gary's patch to enable arbitrary self types.
> > - get more feedback as to what `Untrusted` should make available
> > 
> > In this version I removed the API showcase using tarfs. I did this,
> > because I have added the API to `uaccess.rs`. Also, this version
> > requires [1] to compile the doctests.
> > 
> > [1]: https://lore.kernel.org/rust-for-linux/DM4PR14MB7276E6948E67B3B23D8EA847E9652@DM4PR14MB7276.namprd14.prod.outlook.com/
> 
> This patch series just came up again (well, to be fair I mentioned it),
> so I was curious as to what the status of it was?

I kinda dropped the ball a bit the last weeks :-/

> Also, I think we need to add this to the userslice stuff to mark all
> data coming from userspace as untrusted, so tieing that in soon would be
> good so we don't have to churn a lot of existing code that ends up being
> merged soon (i.e. misc drivers).

Yeah I agree that's going to be the main entry point for untrusted data.
-Sima
-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch