linux-kernel - Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 22 Dec 2015 11:18:34 -0800
From:	Laura Abbott <laura@...bott.name>
To:	Mathias Krause <minipli@...glemail.com>
Cc:	kernel-hardening@...ts.openwall.com,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Kees Cook <keescook@...omium.org>
Subject: Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for
 slab sanitization

On 12/22/15 10:37 AM, Mathias Krause wrote:
> On 22 December 2015 at 18:51, Laura Abbott <laura@...bott.name> wrote:
>>> [snip]
>>>
>>> Related to this, have you checked that the sanitization doesn't
>>> interfere with the various slab handling schemes, namely RCU related
>>> specialties? Not all caches are marked SLAB_DESTROY_BY_RCU, some use
>>> call_rcu() instead, implicitly relying on the semantics RCU'ed slabs
>>> permit, namely allowing a "use-after-free" access to be legitimate
>>> within the RCU grace period. Scrubbing the object during that period
>>> would break that assumption.
>>
>>
>> I haven't looked into that. I was working off the assumption that
>> if the regular SLAB debug poisoning worked so would the sanitization.
>> The regular debug poisoning only checks for SLAB_DESTROY_BY_RCU so
>> how does that work then?
>
> Maybe it doesn't? ;)
>
> How many systems, do you think, are running with enabled DEBUG_SLAB /
> SLUB_DEBUG in production? Not so many, I'd guess. And the ones running
> into issues probably just disable DEBUG_SLAB / SLUB_DEBUG.
>
> Btw, SLUB not only looks for SLAB_DESTROY_BY_RCU but also excludes
> "call_rcu slabs" via other mechanisms. As SLUB is the default SLAB
> allocator for quite some time now, even with enabled SLUB_DEBUG one
> wouldn't be able to trigger RCU related sanitization issues.
>

I've seen SLUB_DEBUG used in stress testing situations but you're
right about production and giving up if there are issues. I'll take
a closer look at this.
  
>>> Speaking of RCU, do you have a plan to support RCU'ed slabs as well?
>>>
>>
>> My only plan was to get the base support in. I didn't have a plan to
>> support RCU slabs but that's certainly something to be done in the
>> future.
>
> "Base support", in my opinion, includes covering the buddy allocator
> as well. Otherwise this feature is incomplete.

Point taken. I'll look at the buddy allocator post-holidays.

It was also pointed out I should be giving you full credit for this
feature originally. I apologize for not doing that. Thanks for
doing the original work and taking the time to review this series.

Thanks,
Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/