linux-kernel - RE: [PATCH 1/3] rust: add userspace pointers

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]

Date: Sat, 10 Feb 2024 14:14:44 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Alice Ryhl' <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>
CC: 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>, Benno Lossin <benno.lossin@...ton.me>, "Andreas
 Hindborg" <a.hindborg@...sung.com>, Kees Cook <keescook@...omium.org>, Al
 Viro <viro@...iv.linux.org.uk>, Andrew Morton <akpm@...ux-foundation.org>,
	"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
	Arve Hjønnevåg <arve@...roid.com>, Todd Kjos
	<tkjos@...roid.com>, Martijn Coenen <maco@...roid.com>, Joel Fernandes
	<joel@...lfernandes.org>, Carlos Llamas <cmllamas@...gle.com>, "Suren
 Baghdasaryan" <surenb@...gle.com>, Arnd Bergmann <arnd@...db.de>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "rust-for-linux@...r.kernel.org"
	<rust-for-linux@...r.kernel.org>, Christian Brauner <brauner@...nel.org>
Subject: RE: [PATCH 1/3] rust: add userspace pointers

...
> > Maybe something like
> >
> >     Every time a memory location is read, the reader's position is advanced by
> >     the read length and the next read will start from there. This helps prevent
> >     accidentally reading the same location twice and causing a TOCTOU bug.

WTF TOCTOU? I'm guessing it is reading things twice and getting
different answers.

That really doesn't match how copying from userspace is used is many places.
Sometimes you really do want to be using offsets and lengths.
For instance the user buffer might contain offsets of items further
down the buffer.
There is also the code (eg ioctl) that does a read-modify-write
on a buffer.


There is also this bit:

> > +    /// Reads the entirety of the user slice.
> > +    ///
> > +    /// Returns `EFAULT` if the address does not currently point to
> > +    /// mapped, readable memory.
> > +    pub fn read_all(self) -> Result<Vec<u8>> {
> > +        self.reader().read_all()
> > +    }
>
> If I understand it correctly, the function will return `EFAULT` if _any_
> address in the interval `[self.0, self.0 + self.1)` does not point to
> mapped, readable memory. Maybe the docs could be more explicit.

That isn't (and can't be) how it works.
access_ok() checks that the buffer isn't in kernel space.
The copy is then done until it actually faults on an invalid address.
In that case the destination buffer has been updated to the point
of failure.

You can't do a check before the copy because another thread can
change the mapping (it would also be horribly expensive).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)