Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 May 2017 09:37:04 +0200
From: Arnd Bergmann <>
To: Andy Lutomirski <>
Cc: Christoph Hellwig <>, Ingo Molnar <>, Greg KH <>, 
	Thomas Garnier <>, Martin Schwidefsky <>, 
	Heiko Carstens <>, Dave Hansen <>, 
	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 <>
Subject: Re: Re: [PATCH v9 1/4] syscalls: Verify address
 limit before returning to user-mode

On Tue, May 9, 2017 at 3:00 PM, Andy Lutomirski <> wrote:
> On Tue, May 9, 2017 at 1:56 AM, Christoph Hellwig <> wrote:
>> On Tue, May 09, 2017 at 08:45:22AM +0200, Ingo Molnar wrote:
>>> We only have ~115 code blocks in the kernel that set/restore KERNEL_DS, it would
>>> be a pity to add a runtime check to every system call ...
>> I think we should simply strive to remove all of them that aren't
>> in core scheduler / arch code.  Basically evetyytime we do the
>>         oldfs = get_fs();
>>         set_fs(KERNEL_DS);
>>         ..
>>         set_fs(oldfs);
>> trick we're doing something wrong, and there should always be better
>> ways to archive it.  E.g. using iov_iter with a ITER_KVEC type
>> consistently would already remove most of them.
> How about trying to remove all of them?  If we could actually get rid
> of all of them, we could drop the arch support, and we'd get faster,
> simpler, shorter uaccess code throughout the kernel.
> The ones in kernel/compat.c are generally garbage.  They should be
> using compat_alloc_user_space().  Ditto for kernel/power/user.c.

compat_alloc_user_space() has some problems too, it adds
complexity to a rarely-tested code path and can add some noticeable
overhead in cases where user space access is slow because of
extra checks.

It's clearly better than set_fs(), but the way I prefer to convert the
code is to avoid both and instead move compat handlers next to
the native code, and splitting out the common code between native
and compat mode into a helper that takes a regular kernel pointer.

I think that's what both Al has done in the past on compat_ioctl()
and select() and what Christoph does in his latest series, but
it seems worth pointing out for others that decide to help out here.


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.