[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <567964F3.2020402@intel.com>
Date: Tue, 22 Dec 2015 06:57:55 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: 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>
Cc: Laura Abbott <laura@...bott.name>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>
Subject: Re: [RFC][PATCH 6/7] mm: Add Kconfig option for
slab sanitization
On 12/21/2015 07:40 PM, Laura Abbott wrote:
> + The tradeoff is performance impact. The noticible impact can vary
> + and you are advised to test this feature on your expected workload
> + before deploying it
What if instead of writing SLAB_MEMORY_SANITIZE_VALUE, we wrote 0's?
That still destroys the information, but it has the positive effect of
allowing a kzalloc() call to avoid zeroing the slab object. It might
mitigate some of the performance impact.
If this is on at compile time, but booted with sanitize_slab=off, is
there a performance impact?
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.
