From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966164AbcKJUh5 (ORCPT ); Thu, 10 Nov 2016 15:37:57 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:48798 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965009AbcKJUh4 (ORCPT ); Thu, 10 Nov 2016 15:37:56 -0500 Date: Thu, 10 Nov 2016 21:37:49 +0100 From: Peter Zijlstra To: Elena Reshetova Cc: kernel-hardening@lists.openwall.com, keescook@chromium.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, h.peter.anvin@intel.com, will.deacon@arm.com, linux-kernel@vger.kernel.org Subject: Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC Message-ID: <20161110203749.GV3117@twins.programming.kicks-ass.net> References: <1478809488-18303-1-git-send-email-elena.reshetova@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1478809488-18303-1-git-send-email-elena.reshetova@intel.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 10, 2016 at 10:24:35PM +0200, Elena Reshetova wrote: > This series brings the PaX/Grsecurity PAX_REFCOUNT > feature support to the upstream kernel. All credit for the > feature goes to the feature authors. > > The name of the upstream feature is HARDENED_ATOMIC > and it is configured using CONFIG_HARDENED_ATOMIC and > HAVE_ARCH_HARDENED_ATOMIC. > > This series only adds x86 support; other architectures are expected > to add similar support gradually. > > More information about the feature can be found in the following > commit messages. No, this should be here. As it stands this is completely without content. In any case, NAK on this approach. Its the wrong way around. _IF_ you want to do a non-wrapping variant, it must not be the default. Since you need to audit every single atomic_t user in the kernel anyway, it doesn't matter. But changing atomic_t to non-wrap by default is not robust, if you forgot one, you can then trivially dos the kernel. That said, I still don't much like this. I would much rather you make kref useful and use that. It still means you get to audit all refcounts in the kernel, but hey, you had to do that anyway.