kernel-hardening - Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAmzW4P+s+z0p=43SfdrPS=+2iuKqvQKZdAwc=zUENuDS0RvxQ@mail.gmail.com>
Date: Wed, 27 Jan 2016 00:21:35 +0900
From: Joonsoo Kim <js1304@...il.com>
To: Christoph Lameter <cl@...ux.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@....com>, Laura Abbott <labbott@...oraproject.org>, 
	Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, 
	Linux Memory Management List <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>, 
	kernel-hardening@...ts.openwall.com, Kees Cook <keescook@...omium.org>
Subject: Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

2016-01-27 0:01 GMT+09:00 Christoph Lameter <cl@...ux.com>:
> On Tue, 26 Jan 2016, Joonsoo Kim wrote:
>
>> I doesn't follow up that discussion, but, I think that reusing
>> SLAB_POISON for slab sanitization needs more changes. I assume that
>> completeness and performance is matter for slab sanitization.
>>
>> 1) SLAB_POISON isn't applied to specific kmem_cache which has
>> constructor or SLAB_DESTROY_BY_RCU flag. For debug, it's not necessary
>> to be applied, but, for slab sanitization, it is better to apply it to
>> all caches.
>
> Those slabs can be legitimately accessed after the objects were freed. You
> cannot sanitize nor poison.

Oops... you are right. I misunderstand what SLAB_DESTROY_BY_RCU is.
Now, it's clear to me.

Thanks.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.