Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 12 May 2017 01:07:41 -0700
From: Christoph Hellwig <>
To: Al Viro <>
Cc: Ingo Molnar <>, Andy Lutomirski <>,
	Christoph Hellwig <>, Greg KH <>,
	Thomas Garnier <>,
	Martin Schwidefsky <>,
	Heiko Carstens <>,
	Dave Hansen <>, Arnd Bergmann <>,
	Thomas Gleixner <>,
	David Howells <>,
	René Nyffenegger <>,
	Andrew Morton <>,
	"Paul E . McKenney" <>,
	"Eric W . Biederman" <>,
	Oleg Nesterov <>,
	Pavel Tikhomirov <>,
	Ingo Molnar <>, "H . Peter Anvin" <>,
	Paolo Bonzini <>, Rik van Riel <>,
	Kees Cook <>,
	Josh Poimboeuf <>,
	Borislav Petkov <>, Brian Gerst <>,
	"Kirill A . Shutemov" <>,
	Christian Borntraeger <>,
	Russell King <>,
	Will Deacon <>,
	Catalin Marinas <>,
	Mark Rutland <>,
	James Morse <>,
	linux-s390 <>,
	LKML <>,
	Linux API <>,
	the arch/x86 maintainers <>,
	"" <>,
	Kernel Hardening <>,
	Linus Torvalds <>,
	Peter Zijlstra <>,
	Mauro Carvalho Chehab <>,
	Palash Bandyopadhyay <>,
	Eric Van Hensbergen <>,
	Richard Weinberger <>
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.