Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1170777AbdDXNKH (ORCPT ); Mon, 24 Apr 2017 09:10:07 -0400 Received: from r00tworld.com ([212.85.137.150]:40981 "EHLO r00tworld.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1170727AbdDXNJj (ORCPT ); Mon, 24 Apr 2017 09:09:39 -0400 From: "PaX Team" To: Peter Zijlstra Date: Mon, 24 Apr 2017 15:08:20 +0200 MIME-Version: 1.0 Subject: Re: [PATCH] x86/refcount: Implement fast refcount_t handling Reply-to: pageexec@freemail.hu CC: Kees Cook , 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: <58FDF8C4.5120.17D092B7@pageexec.freemail.hu> In-reply-to: <20170424111553.p3kbyir4ztsldc56@hirez.programming.kicks-ass.net> References: <20170421220939.GA65363@beast>, <58FDDAC2.11341.175B5A99@pageexec.freemail.hu>, <20170424111553.p3kbyir4ztsldc56@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 15:08:22 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1375 Lines: 31 On 24 Apr 2017 at 13:15, Peter Zijlstra wrote: > On Mon, Apr 24, 2017 at 01:00:18PM +0200, PaX Team wrote: > > On 24 Apr 2017 at 10:32, Peter Zijlstra wrote: > > > > 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? > > The CPUs could each run nested softirq/hardirq/nmi context poking at the > refcount, irrespective of the (preempted) task context. that's fine but are you also assuming that the code executed in each of those contexts leaks the same refcount? otherwise whatever they do to the refcount is no more relevant than a non-leaking preemptible path that runs to completion in a bounded amount of time (i.e., you get temporary bumps and thus need to win yet another set of races to get their effects at once). > > > 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? > > Not the point. All I said was that saying somebody else does it (anybody > else, doesn't matter it was you) isn't an argument for correctness. that was exactly my point: all this applies to you as well. so let me ask the 3rd time: what is your "argument for correctness" for a 0 refcount value check? how does it prevent exploitation?