Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752840Ab2BRQYv (ORCPT ); Sat, 18 Feb 2012 11:24:51 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:39821 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752635Ab2BRQYs (ORCPT ); Sat, 18 Feb 2012 11:24:48 -0500 X-Sasl-enc: mgbHi8qHnx2as//kmug/yuXek2pULxW5F5NKOCSPdBLw 1329582285 Date: Sat, 18 Feb 2012 08:18:49 -0800 From: Greg KH To: Roland Dreier Cc: Djalal Harouni , Vasiliy Kulikov , kernel-hardening@lists.openwall.com, Kees Cook , Ubuntu security discussion , linux-kernel@vger.kernel.org, David Windsor , pageexec@freemail.hu, spender@grsecurity.net Subject: Re: [kernel-hardening] Re: Add overflow protection to kref Message-ID: <20120218161849.GA4176@kroah.com> References: <20120216204515.GH20420@outflux.net> <20120217002405.GB7746@kroah.com> <20120217075945.GA2831@albatros> <20120217175445.GC29902@kroah.com> <20120217193719.GA4187@albatros> <20120217233908.GA24047@dztty> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1461 Lines: 33 On Fri, Feb 17, 2012 at 05:44:57PM -0800, Roland Dreier wrote: > On Fri, Feb 17, 2012 at 3:39 PM, Djalal Harouni wrote: > >> 2) what to do with architectures-loosers? > > There is lib/atomic64.c but with a static hashed array of raw_spinlocks. > > Even leaving aside performance impact of atomic64_t (and probably > in most cases the performance of kref is not important at all), it is > unfortunate to bloat the size from 4 bytes to 8 bytes. > > It seems much better to have some out-of-line code for overflow > checking rather than increasing the size of every data structure > that embeds a kref. Please realize that kref is an in-line structure now. > Greg, I'm not sure why you're opposed to adding this checking... > it's pretty clear that buggy error paths that forget to do a put are > pretty common and will continue to be common in new code, and > making them harder to exploit seems pretty sane to me. > > What's the downside? The downside is that there has not even been a patch sent for any of this. Combine that with a lack of understanding about reference counting and atomic_t usages in the kernel, and the whole thing is ripe for misunderstanding and confusion. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/