From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938317AbcKPJYI (ORCPT ); Wed, 16 Nov 2016 04:24:08 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:44188 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933016AbcKPJYF (ORCPT ); Wed, 16 Nov 2016 04:24:05 -0500 Date: Wed, 16 Nov 2016 10:24:14 +0100 From: Greg KH To: Ingo Molnar Cc: Kees Cook , Peter Zijlstra , 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: <20161116092414.GA2071@kroah.com> References: <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> <20161116083155.GC1270@gmail.com> <20161116085130.GA26208@kroah.com> <20161116090736.GA31395@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161116090736.GA31395@gmail.com> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 16, 2016 at 10:07:37AM +0100, Ingo Molnar wrote: > > * Greg KH wrote: > > > On Wed, Nov 16, 2016 at 09:31:55AM +0100, Ingo Molnar wrote: > > > 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. > > > > Ick, I don't want to have to support nasty #ifdefs for > > "CONFIG_TOTALLY_INSECURE" type options in code logic for the next 20+ > > years, do you? > > I'd write it in C, not CPP, so it would be an 'if', but yeah, it would be extra > code otherwise. > > So I'd restrict this strictly to cases: > > - Where the maintainer absolutely agrees to carry it. > > - Where it's still easy to do technically - for example a single unobtrusive > 'if' condition or so, in cases where the current upstream code still has a > similar structure conductive to the re-introducion of the bug. Such testcases > can be dropped the moment they interfere with active development. > > - Plus an additional approach could be that some of the typical holes can be > reproduced in completely separate code that is not seen by anyone who doesn't > want to see it. Ok, but in looking at a number of "security" fixes over the past year or so, I don't think that many of them would really work well for this. Just look at all of the "don't reference a NULL pointer" bugs for an example of that. > I doubt many bugs have 20 years life times in face of frequent code reorganization > - and if code is static for 20 years then there won't be much extra maintenance > overhead, right? Hah, you obviously are not in charge of maintaining the tty layer :) Anyway, if you want to try this for the next type of security "issue" in your area of the kernel, be my guest, but I think it's going to be a lot harder than you think. thanks, greg k-h