Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1952532AbdDZCSg (ORCPT ); Tue, 25 Apr 2017 22:18:36 -0400 Received: from r00tworld.com ([212.85.137.150]:59520 "EHLO r00tworld.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1952332AbdDZCS1 (ORCPT ); Tue, 25 Apr 2017 22:18:27 -0400 From: "PaX Team" To: Kees Cook Date: Wed, 26 Apr 2017 04:14:06 +0200 MIME-Version: 1.0 Subject: Re: [PATCH] x86/refcount: Implement fast refcount_t handling Reply-to: pageexec@freemail.hu CC: Peter Zijlstra , LKML , 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 , "David S. Miller" , linux-arch , "kernel-hardening@lists.openwall.com" Message-ID: <5900026E.29602.1FC65392@pageexec.freemail.hu> In-reply-to: References: <20170421220939.GA65363@beast>, <58FF3273.8060.1C99E526@pageexec.freemail.hu>, 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]); Wed, 26 Apr 2017 04:14:06 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1648 Lines: 27 On 25 Apr 2017 at 9:39, Kees Cook wrote: > On Tue, Apr 25, 2017 at 4:26 AM, PaX Team wrote: > > INT_MAX threads would be needed when the leaking path is locked so > > that it can only be exercised once and you'll need to get normal > > (balanced) paths preempted just after the increment. if the leaking > > path is lockless (can be exercised in parallel without bounds) then > > 2 threads are enough where the one triggering the signed overflow > > would have to be preempted while the other one does INT_MAX increments > > and trigger the UAF. this is where the other mechanisms i talked about > > in the past become relevant: preemption or interrupts can be disabled > > or negative refcount values can be detected and acted upon (your blind > > copy-pasting effort passed upon this latter opportunity by not > > specializing the 'jo' into 'js' for the refcount case). > > Well, it's not "blind" -- I'm trying to bring the code as-is to > upstream for discussion/examination with as little functional > differences as possible so it's easier to compare apples to apples. you copied code from a version which is at least 2 major kernel revisions behind (so much for those apples), you chose the one version which had a bug that you didn't spot nor fix properly, you didn't realize the opportunity that a special refcount type represents, you claimed refcount underflows aren't exploitable but copied code that would detect signed underflow, you didn't understand the limits and edge cases i explained above... need i go on? doesn't leave one with great confidence in your ability to understand and maintain this code...