From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751531AbdEIGpf (ORCPT ); Tue, 9 May 2017 02:45:35 -0400 Received: from mail-wr0-f195.google.com ([209.85.128.195]:35006 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751139AbdEIGpc (ORCPT ); Tue, 9 May 2017 02:45:32 -0400 Date: Tue, 9 May 2017 08:45:22 +0200 From: Ingo Molnar To: Greg KH Cc: Thomas Garnier , Martin Schwidefsky , Heiko Carstens , Dave Hansen , Arnd Bergmann , Thomas Gleixner , David Howells , =?iso-8859-1?Q?Ren=E9?= Nyffenegger , Andrew Morton , "Paul E . McKenney" , "Eric W . Biederman" , Oleg Nesterov , Pavel Tikhomirov , Ingo Molnar , "H . Peter Anvin" , Andy Lutomirski , 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 , linux-arm-kernel@lists.infradead.org, Kernel Hardening , Linus Torvalds , Peter Zijlstra Subject: Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode Message-ID: <20170509064522.anusoikaalvlux3w@gmail.com> References: <20170428153213.137279-1-thgarnie@google.com> <20170508073352.caqe3fqf7nuxypgi@gmail.com> <20170508124621.GA20705@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170508124621.GA20705@kroah.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Greg KH wrote: > What about a simple coccinelle script to test for this type of thing? > We write it once, add it to the in-kernel body of tests, and then 0-day > runs it on all trees all the time. That should catch this type of > issue, like all of the other "bad programming bus" that the tool > currently catches. Yeah, that would work - but today most of our coccinelle scripts are still pretty verbose, and I think it's important to make this a different category of coccinelle script, which is .config driven where a loud warning yells at us. I.e. force the 'zero warnings tolerated' model. I also noticed that Coccinelle builds are pretty slow, so it would still make sense to have a performance oriented static checking facility that does not have the performance baggage of high level functional languages. I.e. either integrate it into Sparse - or start a kernel integrated static analysis tooling project that would only follow control flow initially - which is what we need here I believe. 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 ... We could also add a runtime check to oops handling to make sure we don't leak KERNEL_DS through kernel crashes, to ease worries about CVE-2010-4258. Thanks, Ingo