Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932483AbdCVUuC (ORCPT ); Wed, 22 Mar 2017 16:50:02 -0400 Received: from mail-it0-f44.google.com ([209.85.214.44]:35618 "EHLO mail-it0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932447AbdCVUtx (ORCPT ); Wed, 22 Mar 2017 16:49:53 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170322203834.67556-1-thgarnie@google.com> From: Thomas Garnier Date: Wed, 22 Mar 2017 13:49:51 -0700 Message-ID: Subject: Re: [PATCH v4 1/4] syscalls: Restore address limit after a syscall To: Andy Lutomirski Cc: Martin Schwidefsky , Heiko Carstens , Dave Hansen , David Howells , Al Viro , Arnd Bergmann , =?UTF-8?Q?Ren=C3=A9_Nyffenegger?= , Andrew Morton , "Paul E . McKenney" , Ingo Molnar , Thomas Gleixner , Oleg Nesterov , Pavel Tikhomirov , Stephen Smalley , 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 , Vladimir Murzin , Will Deacon , Catalin Marinas , Mark Rutland , James Morse , "linux-s390@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Linux API , X86 ML , "linux-arm-kernel@lists.infradead.org" , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1046 Lines: 34 On Wed, Mar 22, 2017 at 1:44 PM, Andy Lutomirski wrote: > On Wed, Mar 22, 2017 at 1:38 PM, Thomas Garnier wrote: >> This patch ensures a syscall does not return to user-mode with a kernel >> address limit. If that happened, a process can corrupt kernel-mode >> memory and elevate privileges. >> >> For example, it would mitigation this bug: >> >> - https://bugs.chromium.org/p/project-zero/issues/detail?id=990 >> >> If the CONFIG_BUG_ON_DATA_CORRUPTION option is enabled, an incorrect >> state will result in a BUG_ON. > > I'm a bit confused about this choice of configurability. I can see > two sensible choices: > > 1. Enable this hardening feature: BUG if there's an exploitable bug. > > 2. Don't enable it at all. > > While it's possible that silently papering over the bug is slightly > faster than BUGging, it will allow bugs to continue to exist > undetected. We can default to BUGging. I think my approach was avoiding doing a BUG_ON just to avoid breaking people. > > --Andy -- Thomas