Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759435AbbDYNxW (ORCPT ); Sat, 25 Apr 2015 09:53:22 -0400 Received: from mail-wg0-f54.google.com ([74.125.82.54]:34777 "EHLO mail-wg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751295AbbDYNxV (ORCPT ); Sat, 25 Apr 2015 09:53:21 -0400 MIME-Version: 1.0 In-Reply-To: References: <1429909549-11726-1-git-send-email-anisse@astier.eu> <1429909549-11726-3-git-send-email-anisse@astier.eu> From: Anisse Astier Date: Sat, 25 Apr 2015 15:52:59 +0200 Message-ID: Subject: Re: [PATCH 2/2] mm/page_alloc.c: add config option to sanitize freed pages To: David Rientjes Cc: Andrew Morton , Mel Gorman , "Kirill A. Shutemov" , Alan Cox , Linus Torvalds , Peter Zijlstra , PaX Team , Brad Spengler , Kees Cook , linux-mm@kvack.org, Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2047 Lines: 51 On Fri, Apr 24, 2015 at 11:38 PM, David Rientjes wrote: > On Fri, 24 Apr 2015, Anisse Astier wrote: > >> diff --git a/mm/Kconfig b/mm/Kconfig >> index 390214d..cb2df5f 100644 >> --- a/mm/Kconfig >> +++ b/mm/Kconfig >> @@ -635,3 +635,15 @@ config MAX_STACK_SIZE_MB >> changed to a smaller value in which case that is used. >> >> A sane initial value is 80 MB. >> + >> +config SANITIZE_FREED_PAGES >> + bool "Sanitize memory pages after free" >> + default n >> + help >> + This option is used to make sure all pages freed are zeroed. This is >> + quite low-level and doesn't handle your slab buffers. >> + It has various applications, from preventing some info leaks to >> + helping kernel same-page merging in virtualised environments. >> + Depending on your workload, it will reduce performance of about 3%. >> + >> + If unsure, say N. > > Objection to allowing this without first enabling some other DEBUG config > option, it should never be a standalone option, but also to pretending to I'm not sure I understand the rationale here. Is it to protect the innocent ? The performance warning and "N" recommendation ought to be enough. I'm not sure depending on DEBUG will help anyone; it will just hinder those who want to use this on a hardened system (where you might not want to have DEBUG enabled). > have any insight into what the performance degredation of it will be. On I fully agree I shouldn't have let the 3% ballpark estimate slip, I'll remove it. > my systems, this would be _massive_. I'm interested in what you mean by "massive". Have you conducted experiments on the impact or is just your gut feeling ? Anyway, I'd be curious to see numbers showing what it looks like on big hardware. Anisse -- 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/