From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932797AbcKPIcC (ORCPT ); Wed, 16 Nov 2016 03:32:02 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35127 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752938AbcKPIb7 (ORCPT ); Wed, 16 Nov 2016 03:31:59 -0500 Date: Wed, 16 Nov 2016 09:31:55 +0100 From: Ingo Molnar To: Kees Cook Cc: Peter Zijlstra , Greg KH , Will Deacon , "Reshetova, Elena" , Arnd Bergmann , Thomas Gleixner , "H. Peter Anvin" , David Windsor , Linus Torvalds , LKML Subject: Re: [RFC][PATCH 7/7] kref: Implement using refcount_t Message-ID: <20161116083155.GC1270@gmail.com> References: <20161114173946.501528675@infradead.org> <20161114174446.832175072@infradead.org> <20161115084009.GB15734@gmail.com> <20161115094744.GG3142@twins.programming.kicks-ass.net> <20161115100359.GA7757@gmail.com> <20161115104608.GH3142@twins.programming.kicks-ass.net> <20161115130315.GA12957@gmail.com> <32165F01-DA9E-4287-9831-6EDE40A71E83@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Kees Cook wrote: > On Tue, Nov 15, 2016 at 11:16 AM, Peter Zijlstra wrote: > > > > > > On 15 November 2016 19:06:28 CET, Kees Cook wrote: > > > >>I'll want to modify this in the future; I have a config already doing > >>"Bug on data structure corruption" that makes the warn/bug choice. > >>It'll need some massaging to fit into the new refcount_t checks, but > >>it should be okay -- there needs to be a way to complete the > >>saturation, etc, but still kill the offending process group. > > > > Ideally we'd create a new WARN like construct that continues in kernel space > > and terminates the process on return to user. That way there would be minimal > > kernel state corruption. Yeah, so the problem is that sometimes you are p0wned the moment you return to a corrupted stack, and some of these checks only detect corruption after the fact. > Right, though I'd like to be conservative about the kernel execution > continuing... I'll experiment with it. So what I'd love to see is to have a kernel option that re-introduces some historic root (and other) holes that can be exploited deterministically - obviously default disabled. I'd restrict this to reasonably 'deterministic' holes, and the exploits themselves could be somewhere in tools/. (Obviously only where the maintainers agree to host the code.) They wouldn't give a root shell, they'd only test whether they reached uid0 (or some other elevated privilege). The advantages of such a suite would be: - Uptodate tests on modern kernels: It would allow the (controlled) testing of live kernel exploits even on the latest kernel - and would allow the testing of various defensive measures. - It would also make sure that defensive measures _remain_ effective against similar categories of bugs. We've had defensive measure regressions in the past, which was only discovered when the next exploit came out ... - Testing of new defensive measures: It would help convert this whole probabilistic and emotion driven "kernel protection" business into something somewhat more rational. For example new protection mechanisms should have a demonstrated ability to turn an existing exploit test into something less dangerous. - Education: It would teach kernel developers the various patterns of holes, right in the code. Maybe being more directly exposed to what can get you p0wned is both a stronger education force plus it could give people ideas about how to protect better. - I also think that collecting the various problems into a single place will give us new insights into patterns, bug counts and various exploit techniques. The disadvantages would be: - Maintenance: do we want to add extra (compiled out by default) code to the kernel whose only purpose is to demonstrate certain types of bugs? - Exposing exploits: Do we want to host a powerful collection of almost-exploits in tools/ ? I don't think we have a choice but to face the problem directly - but others might disagree. I think most of the negatives could be kept small by starting small, allowing maintainers to explicitly opt-in, and observing the effects as we go. But YMMV. Thanks, Ingo