[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+FHmbGvvXg5tYP1w2pjqMnso=VuJnUetobON35B-kEpA@mail.gmail.com>
Date: Tue, 15 Nov 2016 11:23:46 -0800
From: Kees Cook <keescook@...omium.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...nel.org>,
Greg KH <gregkh@...uxfoundation.org>,
Will Deacon <will.deacon@....com>,
"Reshetova, Elena" <elena.reshetova@...el.com>,
Arnd Bergmann <arnd@...db.de>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
David Windsor <dave@...gbits.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 7/7] kref: Implement using refcount_t
On Tue, Nov 15, 2016 at 11:16 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>
>
> On 15 November 2016 19:06:28 CET, Kees Cook <keescook@...omium.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.
Right, though I'd like to be conservative about the kernel execution
continuing... I'll experiment with it.
-Kees
--
Kees Cook
Nexus Security
Powered by blists - more mailing lists