[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170512080741.GA32228@infradead.org>
Date: Fri, 12 May 2017 01:07:41 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...nel.org>,
Christoph Hellwig <hch@...radead.org>, Greg KH <greg@...ah.com>,
Thomas Garnier <thgarnie@...gle.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Dave Hansen <dave.hansen@...el.com>, Arnd Bergmann <arnd@...db.de>,
Thomas Gleixner <tglx@...utronix.de>,
David Howells <dhowells@...hat.com>,
René Nyffenegger <mail@...enyffenegger.ch>,
Andrew Morton <akpm@...ux-foundation.org>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
Oleg Nesterov <oleg@...hat.com>,
Pavel Tikhomirov <ptikhomirov@...tuozzo.com>,
Ingo Molnar <mingo@...hat.com>, "H . Peter Anvin" <hpa@...or.com>,
Paolo Bonzini <pbonzini@...hat.com>, Rik van Riel <riel@...hat.com>,
Kees Cook <keescook@...omium.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Borislav Petkov <bp@...en8.de>, Brian Gerst <brgerst@...il.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Christian Borntraeger <borntraeger@...ibm.com>,
Russell King <linux@...linux.org.uk>,
Will Deacon <will.deacon@....com>,
Catalin Marinas <catalin.marinas@....com>,
Mark Rutland <mark.rutland@....com>,
James Morse <james.morse@....com>,
linux-s390 <linux-s390@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Palash Bandyopadhyay <palash.bandyopadhyay@...exant.com>,
Eric Van Hensbergen <ericvh@...il.com>,
Richard Weinberger <richard@....at>
Subject: Re: Re: [PATCH v9 1/4] syscalls: Verify address
limit before returning to user-mode
On Fri, May 12, 2017 at 12:35:21AM -0700, Christoph Hellwig wrote:
> On Fri, May 12, 2017 at 08:15:49AM +0100, Al Viro wrote:
> > And converting everything to ->read_iter()/->write_iter() means an insane
> > amount of code churn, not to mention coping with random bogosities in
> > semantics. ->read() and ->write() are going to stay around, pretty
> > much indefinitely.
>
> But I don't think kernel users of them have to. I've been digging
> through the calllers and will send an analysis to the list in a bit.
Ok, here is the cleaned up list. The targets for in-kernel I/O
are basically regular files on normal fs, block devices, pipes
and sockets, with a few narrow exceptions and a few unclear cases.
I've added a few maintainers to Cc to clarify, and the list is below:
When looking at kernel_read/kernel_readv/kernel_write/__kernel_write
instances, or vfs_read/vfs_readv/vfs_write/vfs_writev inststances with
set_fs tricks most of them simply require a regular file on a "real"
fs or a block device, pipe, socket:
- various binary loaders: need to be regular files (+ on a "real" fs)
- nandsim: expect a regular file or maybe a block device
- code: expects a regular file
- ecryptfs: expects a regular file
- splice: can be a regular file or device file
- security/keys: regular file
- cachefiles: needs to be a regular file
- coredump: usually a regular file, but possibly a pipe
- acct: regular file
- target: regular file
- nfsd: regular file
- lustre: regular file
- f_mass_storage: regular file, or maybe block device
- autofs: pipe
- btrfs: regular file / pipe / socket
- ima: regular file on specific file systems
Then there are a few interesting ones with specific targets:
- sysctl: regular file on procfs
- mconsole: procfs as far as I can tell. Might be able to further
narrow it down?
- ashmem: regular file on shmem
The nommu mmap code needs to read everything that wants to support
a MAP_PRIVATE mmap, but as far as a I can tell: do a) address limits
not matter for nommu, and b) I have no f***cking idea why it doesn't
use readpage(s) to start with like the MMU code.
And a few that I can't figure:
- cx25821: no idea what this opens, need to confirm with the maintainers
(on Cc)
- 9p: not clear. looks like it might be sockets/pipes
Last but not least we have a driver that's a complete mess:
- series2002: /dev/tty* (drivers is in staging and needs to be rewritten
using the proper in-kernel APIs anyway)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
