From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 12 May 2017 22:30:44 +0200 From: Peter Zijlstra Message-ID: <20170512203044.GI4626@worktop.programming.kicks-ass.net> References: <20170512072802.5a686f23@mschwideX1> <20170512075458.09a3a1ce@mschwideX1> <20170512202106.GO22219@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170512202106.GO22219@n2100.armlinux.org.uk> Subject: Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode To: Russell King - ARM Linux Cc: Kees Cook , Linus Torvalds , Mark Rutland , Kernel Hardening , Greg KH , Heiko Carstens , LKML , David Howells , Dave Hansen , "H . Peter Anvin" , Ingo Molnar , Pavel Tikhomirov , linux-s390 , the arch/x86 maintainers , Will Deacon , Christian Borntraeger , =?iso-8859-1?Q?Ren=E9?= Nyffenegger , Catalin Marinas , "Paul E . McKenney" , Rik van Riel , Arnd Bergmann , Brian Gerst , Borislav Petkov , Al Viro , Andy Lutomirski , Josh Poimboeuf , Thomas Gleixner , Ingo Molnar , "linux-arm-kernel@lists.infradead.org" , Linux API , Oleg Nesterov , Daniel Micay , James Morse , "Eric W . Biederman" , Martin Schwidefsky , Paolo Bonzini , Andrew Morton , Thomas Garnier , "Kirill A . Shutemov" List-ID: On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > I'm clearly not explaining things well enough. I shouldn't say > > "corruption", I should say "malicious manipulation". The methodology > > of attacks against the stack are quite different from the other kinds > > of attacks like use-after-free, heap overflow, etc. Being able to > > exhaust the kernel stack (either due to deep recursion or unbounded > > alloca()) > > I really hope we don't have alloca() use in the kernel. Do you have > evidence to support that assertion? > > IMHO alloca() (or similar) should not be present in any kernel code > because we have a limited stack - we have kmalloc() etc for that kind > of thing. On stack variable length arrays get implemented by the compiler doing alloca(), and we sadly have a few of those around. But yes, fully agreed on the desirability of alloca() and things. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode Date: Fri, 12 May 2017 22:30:44 +0200 Message-ID: <20170512203044.GI4626@worktop.programming.kicks-ass.net> References: <20170512072802.5a686f23@mschwideX1> <20170512075458.09a3a1ce@mschwideX1> <20170512202106.GO22219@n2100.armlinux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20170512202106.GO22219@n2100.armlinux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Russell King - ARM Linux Cc: Mark Rutland , Brian Gerst , Kernel Hardening , Catalin Marinas , Heiko Carstens , Oleg Nesterov , David Howells , Dave Hansen , "H . Peter Anvin" , Ingo Molnar , Pavel Tikhomirov , linux-s390 , the arch/x86 maintainers , Christian Borntraeger , =?iso-8859-1?Q?Ren=E9?= Nyffenegger , Greg KH , "Paul E . McKenney" , Rik van Riel , Kees Cook , Arnd Bergmann , Will Deacon , Borislav Petkov , Al Viro List-Id: linux-api@vger.kernel.org On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > I'm clearly not explaining things well enough. I shouldn't say > > "corruption", I should say "malicious manipulation". The methodology > > of attacks against the stack are quite different from the other kinds > > of attacks like use-after-free, heap overflow, etc. Being able to > > exhaust the kernel stack (either due to deep recursion or unbounded > > alloca()) > > I really hope we don't have alloca() use in the kernel. Do you have > evidence to support that assertion? > > IMHO alloca() (or similar) should not be present in any kernel code > because we have a limited stack - we have kmalloc() etc for that kind > of thing. On stack variable length arrays get implemented by the compiler doing alloca(), and we sadly have a few of those around. But yes, fully agreed on the desirability of alloca() and things. From mboxrd@z Thu Jan 1 00:00:00 1970 From: peterz@infradead.org (Peter Zijlstra) Date: Fri, 12 May 2017 22:30:44 +0200 Subject: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode In-Reply-To: <20170512202106.GO22219@n2100.armlinux.org.uk> References: <20170512072802.5a686f23@mschwideX1> <20170512075458.09a3a1ce@mschwideX1> <20170512202106.GO22219@n2100.armlinux.org.uk> Message-ID: <20170512203044.GI4626@worktop.programming.kicks-ass.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > I'm clearly not explaining things well enough. I shouldn't say > > "corruption", I should say "malicious manipulation". The methodology > > of attacks against the stack are quite different from the other kinds > > of attacks like use-after-free, heap overflow, etc. Being able to > > exhaust the kernel stack (either due to deep recursion or unbounded > > alloca()) > > I really hope we don't have alloca() use in the kernel. Do you have > evidence to support that assertion? > > IMHO alloca() (or similar) should not be present in any kernel code > because we have a limited stack - we have kmalloc() etc for that kind > of thing. On stack variable length arrays get implemented by the compiler doing alloca(), and we sadly have a few of those around. But yes, fully agreed on the desirability of alloca() and things.