[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0rAjaw+U0smH45H6mVJ88P_Q033JDeKODQ+VmTHfKHQw@mail.gmail.com>
Date: Fri, 12 May 2017 10:20:42 +0200
From: Arnd Bergmann <arnd@...db.de>
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>,
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>
Subject: Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address
limit before returning to user-mode
On Fri, May 12, 2017 at 10:11 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
> Anyway, what's special about modules? IDGI...
One of the arguments that came up earlier was code in external modules
being mostly unaudited, sometimes without any source code available
at all but still used in devices.
If modules can't do set_fs() any more, this could eliminate bugs with
unpaired set_fs in those modules.
Limiting factors of course are:
- embedded systems that ship come with their own kernels (as opposed
to using whatever users have, or relying on binary distros) can just
make it available to modules again, by reverting the patch
- As Christoph said, they could have an open-coded set_fs in the
driver
- Whatever other method a clueless driver write might come up with
isn't necessarily better than set_fs().
Arnd
Powered by blists - more mailing lists