[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <568C8741.4040709@labbott.name>
Date: Tue, 5 Jan 2016 19:17:21 -0800
From: Laura Abbott <laura@...bott.name>
To: Kees Cook <keescook@...omium.org>
Cc: 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 <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: [RFC][PATCH 0/7] Sanitization of slabs based on grsecurity/PaX
On 1/5/16 4:09 PM, Kees Cook wrote:
> On Tue, Dec 22, 2015 at 12:04 PM, Laura Abbott <laura@...bott.name> wrote:
>> On 12/22/15 8:08 AM, Christoph Lameter wrote:
>>>
>>> On Mon, 21 Dec 2015, Laura Abbott wrote:
>>>
>>>> The biggest change from PAX_MEMORY_SANTIIZE is that this feature
>>>> sanitizes
>>>> the SL[AOU]B allocators only. My plan is to work on the buddy allocator
>>>> santization after this series gets picked up. A side effect of this is
>>>> that allocations which go directly to the buddy allocator (i.e. large
>>>> allocations) aren't sanitized. I'd like feedback about whether it's worth
>>>> it to add sanitization on that path directly or just use the page
>>>> allocator sanitization when that comes in.
>
> This looks great! I love the added lkdtm tests, too. Very cool.
>
>>> I am not sure what the point of this patchset is. We have a similar effect
>>> to sanitization already in the allocators through two mechanisms:
>>>
>>> 1. Slab poisoning
>>> 2. Allocation with GFP_ZERO
>>>
>>> I do not think we need a third one. You could accomplish your goals much
>>> easier without this code churn by either
>>>
>>> 1. Improve the existing poisoning mechanism. Ensure that there are no
>>> gaps. Security sensitive kernel slab caches can then be created with
>>> the POISONING flag set. Maybe add a Kconfig flag that enables
>>> POISONING for each cache? What was the issue when you tried using
>>> posining for sanitization?
>>
>> The existing poisoning does work for sanitization but it's still a debug
>> feature. It seemed more appropriate to keep debug features and non-debug
>> features separate hence the separate option and configuration.
>
> What stuff is intertwined in the existing poisoning that makes it
> incompatible/orthogonal?
>
It's not the poisoning per se that's incompatible, it's how the poisoning is
set up. At least for slub, the current poisoning is part of SLUB_DEBUG which
enables other consistency checks on the allocator. Trying to pull out just
the poisoning for use when SLUB_DEBUG isn't on would result in roughly what
would be here anyway. I looked at trying to reuse some of the existing poisoning
and came to the conclusion it was less intrusive to the allocator to keep it
separate.
Thanks,
Laura
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
