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

Path	csiph.com!aioe.org!bofh.it!news.nic.it!robomod
From	Laura Abbott <laura@labbott.name>
Newsgroups	linux.kernel
Subject	Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for slab sanitization
Date	Wed, 06 Jan 2016 03:50:01 +0100
Message-ID	<qNMkF-3kl-1@gated-at.bofh.it> (permalink)
References	<qIm7v-75a-1@gated-at.bofh.it> <qIm7v-75a-3@gated-at.bofh.it> <qIwzU-5fu-1@gated-at.bofh.it> <qIxZ0-6go-27@gated-at.bofh.it> <qIyV4-6R0-23@gated-at.bofh.it> <qIyV4-6R0-25@gated-at.bofh.it> <qIyV4-6R0-21@gated-at.bofh.it> <qIzxM-7jr-19@gated-at.bofh.it> <qIzHs-7mN-11@gated-at.bofh.it> <qIADv-7Ym-5@gated-at.bofh.it> <qNK9c-1YP-11@gated-at.bofh.it>
Dkim-Signature	v=1; a=rsa-sha256; c=relaxed/relaxed; d=labbott.name; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=8Pa12jDkTaagL5Bi5D9WfuAklPiDmiDxxyJv8MMXs9M=; b=Pp3E4Cvd/03QItsQN8SpXo0wWZbBJiKCALU4EVWgb3Rh8nehp54O+vxA9ifHg+eGzB Z0J2nsCAS5jCLr0CNu0nDoqCLFr68y39jQ6kCXTuc7vee/6DwIsPXUB6fshoGkKtCoK4 W/vcq+TGvNp8bpSD0hP2+gDWYr2xP8GbhiYd8=
X-Google-Dkim-Signature	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=8Pa12jDkTaagL5Bi5D9WfuAklPiDmiDxxyJv8MMXs9M=; b=U5jlYWVRPTSrj+NNVn8fm2jPYQ/pc8LL50t/xM6GpVHZaYbnZYT63e2s6tsYVA+46a Zv72gL2FoRnQ6iOMgLgObrfUc12mEO5mCyNgOKfnXnkNotJmlny6t/LkcoiAngINezoW 0qOz+2BuPCMo8fOKqPNYix6i7zanChQxhZ8OmJ65JznrLZa5Sk7Ajb3oqQ14px7ZaKpn I6ZAot8c3qivnNgFu7lmSxcwMAjzHpPTdhvhOyauJzqkymTqzo/+C3tzQkOFwkJqK16r s3l9rJaoK5CvQODvuu4SzW/G2ZW0Se9DVfZGLzU86Xly0M/01LO58WuGAEFr9P+2aCZc HovQ==
X-Gm-Message-State	ALoCoQlQwyNVt5NMhAu3ntUdD7ik9jqWxn1QvCWWxeJeegTrps4oNLyhI40wX4cgc+eyzFkLSfBnBU7+tlMy7GKhKMLHbiZM6A==
X-Received	by 10.98.14.134 with SMTP id 6mr8634416pfo.6.1452048373313; Tue, 05 Jan 2016 18:46:13 -0800 (PST)
User-Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version	1.0
Content-Type	text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding	7bit
Sender	robomod@news.nic.it
List-ID	<linux-kernel.vger.kernel.org>
X-Mailing-List	linux-kernel@vger.kernel.org
Approved	robomod@news.nic.it
Lines	58
Organization	linux.* mail to news gateway
X-Original-Cc	Dave Hansen <dave.hansen@intel.com>, Christoph Lameter <cl@linux.com>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, Pekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Andrew Morton <akpm@linux-foundation.org>, Linux-MM <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>
X-Original-Date	Tue, 5 Jan 2016 18:46:11 -0800
X-Original-Message-ID	<568C7FF3.9070408@labbott.name>
X-Original-References	<1450755641-7856-1-git-send-email-laura@labbott.name> <1450755641-7856-7-git-send-email-laura@labbott.name> <567964F3.2020402@intel.com> <alpine.DEB.2.20.1512221023550.2748@east.gentwo.org> <567986E7.50107@intel.com> <alpine.DEB.2.20.1512221124230.14335@east.gentwo.org> <56798851.60906@intel.com> <alpine.DEB.2.20.1512221207230.14406@east.gentwo.org> <5679943C.1050604@intel.com> <5679A0CB.3060707@labbott.name> <CAGXu5jLe69KvVOGE2kHtJk+Ueik4OX9YyYAk_NhRufOEVkLUdQ@mail.gmail.com>
X-Original-Sender	linux-kernel-owner@vger.kernel.org
Xref	csiph.com linux.kernel:1302354

Show key headers only | View raw

On 1/5/16 4:29 PM, Kees Cook wrote:
> On Tue, Dec 22, 2015 at 11:13 AM, Laura Abbott <laura@labbott.name> wrote:
>> On 12/22/15 10:19 AM, Dave Hansen wrote:
>>>
>>> On 12/22/2015 10:08 AM, Christoph Lameter wrote:
>>>>
>>>> On Tue, 22 Dec 2015, Dave Hansen wrote:
>>>>>>
>>>>>> Why would you use zeros? The point is just to clear the information
>>>>>> right?
>>>>>> The regular poisoning does that.
>>>>>
>>>>>
>>>>> It then allows you to avoid the zeroing at allocation time.
>>>>
>>>>
>>>> Well much of the code is expecting a zeroed object from the allocator and
>>>> its zeroed at that time. Zeroing makes the object cache hot which is an
>>>> important performance aspect.
>>>
>>>
>>> Yes, modifying this behavior has a performance impact.  It absolutely
>>> needs to be evaluated, and I wouldn't want to speculate too much on how
>>> good or bad any of the choices are.
>>>
>>> Just to reiterate, I think we have 3 real choices here:
>>>
>>> 1. Zero at alloc, only when __GFP_ZERO
>>>      (behavior today)
>>> 2. Poison at free, also Zero at alloc (when __GFP_ZERO)
>>>      (this patch's proposed behavior, also what current poisoning does,
>>>       doubles writes)
>>> 3. Zero at free, *don't* Zero at alloc (when __GFP_ZERO)
>>>      (what I'm suggesting, possibly less perf impact vs. #2)
>>>
>>>
>>
>> poisoning with non-zero memory makes it easier to determine that the error
>> came from accessing the sanitized memory vs. some other case. I don't think
>> the feature would be as strong if the memory was only zeroed vs. some other
>> data value.
>
> I would tend to agree. If there are significant perf improvements for
> "3" above, that should be easy to add on later as another choice.
>

I was looking at the sanitization for the buddy allocator that exists in
grsecurity and that does option #3 (zero at free, skip __GFP_ZERO).
I'm going to look into adding that as an option for the slab allocator
and see what the performance numbers show.

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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for  slab sanitization Kees Cook <keescook@chromium.org> - 2016-01-06 01:30 +0100
  Re: [kernel-hardening] [RFC][PATCH 6/7] mm: Add Kconfig option for  slab sanitization Laura Abbott <laura@labbott.name> - 2016-01-06 03:50 +0100

csiph-web