From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753495AbdF0T3t (ORCPT ); Tue, 27 Jun 2017 15:29:49 -0400 Received: from mga02.intel.com ([134.134.136.20]:27004 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752646AbdF0T3l (ORCPT ); Tue, 27 Jun 2017 15:29:41 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,271,1496127600"; d="scan'208";a="119478160" Date: Tue, 27 Jun 2017 12:29:39 -0700 From: Andi Kleen To: "Jason A. Donenfeld" Cc: Greg Kroah-Hartman , Kees Cook , Ingo Molnar , Peter Zijlstra , Thomas Hellstrom , Daniel Micay , LKML Subject: Re: [PATCH] kref: Avoid null pointer dereference after WARN Message-ID: <20170627192939.GJ23705@tassilo.jf.intel.com> References: <20170627035215.GA132342@beast> <20170627070626.GH29909@kroah.com> <20170627110013.GA3026@zx2c4.com> <20170627144918.GG23705@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 27, 2017 at 09:11:28PM +0200, Jason A. Donenfeld wrote: > On Tue, Jun 27, 2017 at 4:49 PM, Andi Kleen wrote: > > Is there any data how many security holes this would have > > caught? Please no hand waving. A lot of the recent > > security patches seem to have gone in with just a lot of > > hand waving and security theater > > I don't practice security theater. What an offensive insinuation. > Maybe you just meant this about other patches, however. I'm not naming names, but there was a recent patch that seemed to have fixed one very extremely specific bug, but made every kernel exit forever slower. That was a classic case IMHO -- the Linux equivalent of shoes at airport checkpoints. > The point was that if there prior was a WARN_ON, this needs to be a > BUG_ON, since if the WARN_ON was put there with any validity, > continuing after it will always be "fatal and potentially > exploitable". Thus, it'd be better to change that to simply "fatal but That's not necessarily true. Especially not for a release. Typically you would hit if partial teardown on an initialization failure is incorrect. But that's not exploitable at all. > The bigger question, though, is the value of these checks in the first > place. Has anybody written a coccinelle check to look into this > statically? Has it historically been a useful thing for driver > developers to have? Is it good defense in depth or is it overkill? At > the very least, the original authors of kref thought a WARN_ON was > warranted, which means probably a BUG_ON is a sensible fix, until > somebody does the work of investigating these more careful questions. Right that's the question that should have been answered before this patch. I don't think it was ever intended to be a defense, just as a hint for driver developers. My suspicion is that they're mostly useless. -Andi