From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751891AbdDHFH5 (ORCPT ); Sat, 8 Apr 2017 01:07:57 -0400 Received: from mail.kernel.org ([198.145.29.136]:45576 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751148AbdDHFHs (ORCPT ); Sat, 8 Apr 2017 01:07:48 -0400 MIME-Version: 1.0 In-Reply-To: References: <1490811363-93944-1-git-send-email-keescook@chromium.org> <1490811363-93944-5-git-send-email-keescook@chromium.org> From: Andy Lutomirski Date: Fri, 7 Apr 2017 22:07:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap() To: Daniel Micay Cc: Andy Lutomirski , Mathias Krause , Thomas Gleixner , Kees Cook , "kernel-hardening@lists.openwall.com" , Mark Rutland , Hoeun Ryu , PaX Team , Emese Revfy , Russell King , X86 ML , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Peter Zijlstra Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 7, 2017 at 9:21 PM, Daniel Micay wrote: >>> Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP)) >>> somewhere sensible should make those "leaks" visible fast -- and their >>> exploitation impossible, i.e. fail hard. >> >> The leaks surely exist and now we'll just add an exploitable BUG. > > That didn't seem to matter for landing a rewrite of KSTACKOVERFLOW > with a bunch of *known* DoS bugs dealt with in grsecurity and those > were known issues that were unfixed for no apparent reason other than > keeping egos intact. It looks like there are still some left... > > In that case, there also wasn't a security/performance advantage. This is wildly off topic, but I think it's worth answering anyway because there's an important point here: grsecurity and PaX are great projects. They have a lot of good ideas, and they're put together quite nicely. The upstream kernel should *not* do things differently from they way they are in grsecurity/PaX just because it wants to be different. Conversely, the upstream kernel should not do things the same way as PaX just to be more like PaX. Keep in mind that the upstream kernel and grsecurity/PaX operate under different constraints. The upstream kernel tries to keep itself clean and to make tree-wide updates rather that keeping compatibility stuff around. PaX and grsecurity presumably want to retain some degree of simplicity when porting to newer upstream versions. In the context of virtually mapped stacks / KSTACKOVERFLOW, this naturally leads to different solutions. The upstream kernel had a bunch of buggy drivers that played badly with virtually mapped stacks. grsecurity sensibly went for the approach where the buggy drivers kept working. The upstream kernel went for the approach of fixing the drivers rather than keeping a compatibility workaround. Different constraints, different solutions. The point being that, if someone sends a patch to the x86 entry code that's justified by "be like PaX" or by "be different than PaX", that's not okay. It needs a real justification that stands on its own. In the case of rare writes or pax_open_kernel [1] or whatever we want to call it, CR3 would work without arch-specific code, and CR0 would not. That's an argument for CR3 that would need to be countered by something. (Sure, avoiding leaks either way might need arch changes. OTOH, a *randomized* CR3-based approach might not have as much of a leak issue to begin with.) [1] Contrary to popular belief, I don't sit around reading grsecurity code or config options, so I really don't know what this thing is called.