From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755261AbcKPKPw (ORCPT <rfc822;w@1wt.eu>);
        Wed, 16 Nov 2016 05:15:52 -0500
Received: from merlin.infradead.org ([205.233.59.134]:39588 "EHLO
        merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752263AbcKPKPv (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 16 Nov 2016 05:15:51 -0500
Date: Wed, 16 Nov 2016 11:15:48 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Kees Cook <keescook@chromium.org>,
        Greg KH <gregkh@linuxfoundation.org>,
        Will Deacon <will.deacon@arm.com>,
        "Reshetova, Elena" <elena.reshetova@intel.com>,
        Arnd Bergmann <arnd@arndb.de>, Thomas Gleixner <tglx@linutronix.de>,
        "H. Peter Anvin" <hpa@zytor.com>, David Windsor <dave@progbits.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 7/7] kref: Implement using refcount_t
Message-ID: <20161116101548.GO3142@twins.programming.kicks-ass.net>
References: <20161114174446.832175072@infradead.org>
 <20161115084009.GB15734@gmail.com>
 <20161115094744.GG3142@twins.programming.kicks-ass.net>
 <20161115100359.GA7757@gmail.com>
 <20161115104608.GH3142@twins.programming.kicks-ass.net>
 <20161115130315.GA12957@gmail.com>
 <CAGXu5jLRbz_nZMKNTUY8k5C-cf8=8_G8pE3fFYkJ8U9Yjb5p9g@mail.gmail.com>
 <32165F01-DA9E-4287-9831-6EDE40A71E83@infradead.org>
 <CAGXu5j+FHmbGvvXg5tYP1w2pjqMnso=VuJnUetobON35B-kEpA@mail.gmail.com>
 <20161116083155.GC1270@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161116083155.GC1270@gmail.com>
User-Agent: Mutt/1.5.23.1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Nov 16, 2016 at 09:31:55AM +0100, Ingo Molnar wrote:
> 
> * Kees Cook <keescook@chromium.org> wrote:
> 
> > On Tue, Nov 15, 2016 at 11:16 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > >
> > > On 15 November 2016 19:06:28 CET, Kees Cook <keescook@chromium.org> wrote:
> > >
> > >>I'll want to modify this in the future; I have a config already doing
> > >>"Bug on data structure corruption" that makes the warn/bug choice.
> > >>It'll need some massaging to fit into the new refcount_t checks, but
> > >>it should be okay -- there needs to be a way to complete the
> > >>saturation, etc, but still kill the offending process group.
> > >
> > > Ideally we'd create a new WARN like construct that continues in kernel space 
> > > and terminates the process on return to user. That way there would be minimal 
> > > kernel state corruption.
> 
> Yeah, so the problem is that sometimes you are p0wned the moment you return to a 
> corrupted stack, and some of these checks only detect corruption after the fact.

So the case here is about refcounts, with the saturation semantics we
avoid the use-after-free case which is all this is about. So actually
continuation of execution is harmless vs the attack vector in question.

Corrupting the stack is another attack vector, one that refcount
overflow is entirely unrelated to and not one I think we should consider
here.

The problem with BUG and insta killing the task is that refcounts are
typically done under locks, if you kill the task before the unlock,
you've wrecked kernel state in unrecoverable ways.