linux-kernel - Re: [PATCH 1/3] rust: add untrusted data abstraction

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: <2024091858-surrender-broadcast-e11f@gregkh>
Date: Wed, 18 Sep 2024 19:09:24 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Simona Vetter <simona.vetter@...ll.ch>, Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Wedson Almeida Filho <wedsonaf@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Andreas Hindborg <a.hindborg@...sung.com>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] rust: add untrusted data abstraction

On Wed, Sep 18, 2024 at 03:40:54PM +0000, Benno Lossin wrote:
> >> Yeah, we need more users of this to know the full way to express this
> >> correctly. I would like to avoid huge refactorings in the future.
> > 
> > I think adding it to the copy_*_user functions we already have in
> > upstream, and then asking Alice to rebase binder should be a really solid
> > real-world testcase. And I think currently for the things in-flight
> > copy*user is going to be the main source of untrusted data anyway, not so
> > much page cache folios.
> 
> Sure. I chose tarfs as the use-case, because Greg mentioned to me that
> it would benefit from adding this API. (I have no prior linux kernel
> experience, so you giving me some pointers where this will be useful is
> very helpful!)

I just had tarfs as an easy example where we were reading data off the
disk and acting on it, in a way just like C where if the data is
corrupted we can do "not normal" things.  Sorry it got tied up with
folios, that is not the normal way drivers work, they either get data
from userspace through a char device node (ioctls) or from hardware
(memory copies/reads/something) and for them the "untrusted data"
abstraction should be much simpler than dealing with a folio.

We don't really have any other good examples of drivers in rust yet that
I could find other than maybe binder, but Alice has already posted her
solution for how to handle untrusted data there (comes in through a char
device node and/or a filesystem entry point) but it's much more complex
and possibly harder to use as a simple example of the api ideas.

thanks,

greg k-h