[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4a6c0105-b084-aa87-6a2b-0650613df6ac@linux.com>
Date: Mon, 31 Jul 2017 23:17:19 +0300
From: Alexander Popov <alex.popov@...ux.com>
To: Christopher Lameter <cl@...ux.com>,
Kees Cook <keescook@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...nel.org>,
Josh Triplett <josh@...htriplett.org>,
Andy Lutomirski <luto@...nel.org>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
Tejun Heo <tj@...nel.org>, Daniel Mack <daniel@...que.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Helge Deller <deller@....de>, Rik van Riel <riel@...hat.com>,
Linux-MM <linux-mm@...ck.org>, Tycho Andersen <tycho@...ker.com>,
LKML <linux-kernel@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>
Subject: Re: [v3] mm: Add SLUB free list pointer obfuscation
Hello Christopher and Kees,
Excuse me for the delayed reply.
On 28.07.2017 02:53, Christopher Lameter wrote:
> On Fri, 28 Jul 2017, Alexander Popov wrote:
>
>> I don't really like ignoring double-free. I think, that:
>> - it will hide dangerous bugs in the kernel,
>> - it can make some kernel exploits more stable.
>> I would rather add BUG_ON to set_freepointer() behind SLAB_FREELIST_HARDENED. Is
>> it fine?
>
> I think Kees already added some logging output.
Hm, I don't see anything like that in v4 of "SLUB free list pointer
obfuscation": https://patchwork.kernel.org/patch/9864165/
>> At the same time avoiding the consequences of some double-free errors is better
>> than not doing that. It may be considered as kernel "self-healing", I don't
>> know. I can prepare a second patch for do_slab_free(), as you described. Would
>> you like it?
>
> The SLUB allocator is already self healing if you enable the option to do
> so on bootup (covers more than just the double free case). What you
> propose here is no different than that and just another way of having
> similar functionality. In the best case it would work the same way.
Ok, I see. Thanks.
Best regards,
Alexander
Powered by blists - more mailing lists