linux-kernel - RE: [PATCH RFC] uaccess: user_access_begin_after_access

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: <a6d865f0dc7a427bb180cf451b8d470f@AcuMS.aculab.com>
Date:   Wed, 3 Jun 2020 08:08:17 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Al Viro' <viro@...iv.linux.org.uk>
CC:     "'Michael S. Tsirkin'" <mst@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jason Wang <jasowang@...hat.com>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>
Subject: RE: [PATCH RFC] uaccess: user_access_begin_after_access_ok()

From: Al Viro <viro@....linux.org.uk> On Behalf Of Al Viro
> Sent: 02 June 2020 22:58
> On Tue, Jun 02, 2020 at 08:41:38PM +0000, David Laight wrote:
> 
> > In which case you need a 'user_access_begin' that takes the mm
> > as an additional parameter.
> 
> 	What does any of that have to do with mm?  Details, please.

Actually probably nothing.

I was sort of thinking that maybe the user process's memory
map (mm?) would be temporarily 'attached' to the kernel thread
so that it used the normal copy_to/from_user() fault
handling to access the 'other' process.

In which case you'd want to do the bound check against the
limit of the user addresses in the mm rather than those of
the current process.

But later posts probably imply that it is all done differently.

	David

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