Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1169047AbdDXLBr (ORCPT ); Mon, 24 Apr 2017 07:01:47 -0400 Received: from r00tworld.com ([212.85.137.150]:52888 "EHLO r00tworld.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1168931AbdDXLBj (ORCPT ); Mon, 24 Apr 2017 07:01:39 -0400 From: "PaX Team" To: Kees Cook , Peter Zijlstra Date: Mon, 24 Apr 2017 13:00:18 +0200 MIME-Version: 1.0 Subject: Re: [PATCH] x86/refcount: Implement fast refcount_t handling Reply-to: pageexec@freemail.hu CC: linux-kernel@vger.kernel.org, Eric Biggers , Christoph Hellwig , "axboe@kernel.dk" , James Bottomley , Elena Reshetova , Hans Liljestrand , David Windsor , x86@kernel.org, Ingo Molnar , Arnd Bergmann , Greg Kroah-Hartman , Jann Horn , davem@davemloft.net, linux-arch@vger.kernel.org, kernel-hardening@lists.openwall.com Message-ID: <58FDDAC2.11341.175B5A99@pageexec.freemail.hu> In-reply-to: <20170424083250.h2wv2exbi4ytigac@hirez.programming.kicks-ass.net> References: <20170421220939.GA65363@beast>, <20170424083250.h2wv2exbi4ytigac@hirez.programming.kicks-ass.net> X-mailer: Pegasus Mail for Windows (4.72.572) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.12 (r00tworld.com [212.85.137.150]); Mon, 24 Apr 2017 13:00:19 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1142 Lines: 28 On 24 Apr 2017 at 10:32, Peter Zijlstra wrote: > On Fri, Apr 21, 2017 at 03:09:39PM -0700, Kees Cook wrote: > > This patch ports the x86-specific atomic overflow handling from PaX's > > PAX_REFCOUNT to the upstream refcount_t API. This is an updated version > > from PaX that eliminates the saturation race condition by resetting the > > atomic counter back to the INT_MAX saturation value on both overflow and > > underflow. To win a race, a system would have to have INT_MAX threads > > simultaneously overflow before the saturation handler runs. note that the above is wrong (and even contradicting itself and the code). > And is this impossible? Highly unlikely I'll grant you, but absolutely > impossible? here's my analysis from a while ago: http://www.openwall.com/lists/kernel-hardening/2017/01/05/19 > Also, you forgot nr_cpus in your bound. Afaict the worst case here is > O(nr_tasks + 3*nr_cpus). what does nr_cpus have to do with winning the race? > Because PaX does it, is not a correctness argument. And this really > wants one. heh, do you want to tell me about how checking for a 0 refcount prevents exploiting a bug?