From: Mel Gorman <mgorman@suse.de> To: Anisse Astier <anisse@astier.eu> Cc: Andrew Morton <akpm@linux-foundation.org>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, David Rientjes <rientjes@google.com>, Alan Cox <gnomes@lxorguk.ukuu.org.uk>, Linus Torvalds <torvalds@linux-foundation.org>, Peter Zijlstra <peterz@infradead.org>, PaX Team <pageexec@freemail.hu>, Brad Spengler <spender@grsecurity.net>, Kees Cook <keescook@chromium.org>, Andi Kleen <andi@firstfloor.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>, linux-mm@kvack.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 0/3] Sanitizing freed pages Date: Tue, 19 May 2015 13:46:44 +0100 [thread overview] Message-ID: <20150519124644.GD2462@suse.de> (raw) In-Reply-To: <1431613188-4511-1-git-send-email-anisse@astier.eu> On Thu, May 14, 2015 at 04:19:45PM +0200, Anisse Astier wrote: > Hi, > > I'm trying revive an old debate here[1], though with a simpler approach than > was previously tried. This patch series implements a new option to sanitize > freed pages, a (very) small subset of what is done in PaX/grsecurity[3], > inspired by a previous submission [4]. > > There are a few different uses that this can cover: > - some cases of use-after-free could be detected (crashes), although this not > as efficient as KAsan/kmemcheck They're not detected, they're hidden. I'm currently seeing problems with a glibc update in userspace where applications are crashing because glibc returns buffers with uninitialised data that would previously have been zero. In every case so far, they were application bugs that need fixing. Having the kernel crash due to uninitialised memory use is bad but hiding it is not better. > - it can help with long-term memory consumption in an environment with > multiple VMs and Kernel Same-page Merging on the host. [2] This is not quantified but a better way of dealing with that problem would be for a guest to signal to the host when a page is really free. I vaguely recall that s390 has some hinting of this nature. While I accept there may be some benefits in some cases, I think it's a weak justification for always zeroing pages on free. > - finally, it can reduce infoleaks, although this is hard to measure. > It obscures them. That is leaving aside the fact that this has to be enabled at kconfig time which is unlikely to happen on a distribution config. Not many workloads depend on the freed path as such but streaming readers are one once the files are larger than memory. > The approach is voluntarily kept as simple as possible. A single configuration > option, no command line option, no sysctl nob. It can of course be changed, > although I'd be wary of runtime-configuration options that could be used for > races. > > I haven't been able to measure a meaningful performance difference when > compiling a (in-cache) kernel; I'd be interested to see what difference it > makes with your particular workload/hardware (I suspect mine is CPU-bound on > this small laptop). > What did you use to determine this and did you check if it was hitting the free paths heavily while it's running? It can be very easy to hide the cost of something like this if all the frees happen at exit. Overall, I'm not a big fan of this series. I think it would have made more sense to use non-temporal cleaning on pages if they are freed by kswapd or on a non-critical path like exit and then track if the page was already freed during allocation. Then add a runtime sysctl to make that strict and force all zeroing on all frees. As it is, I think it'll have very few users because of the need to enable it at kernel build time and then incur an unavoidable penalty. -- Mel Gorman SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de> To: Anisse Astier <anisse@astier.eu> Cc: Andrew Morton <akpm@linux-foundation.org>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, David Rientjes <rientjes@google.com>, Alan Cox <gnomes@lxorguk.ukuu.org.uk>, Linus Torvalds <torvalds@linux-foundation.org>, Peter Zijlstra <peterz@infradead.org>, PaX Team <pageexec@freemail.hu>, Brad Spengler <spender@grsecurity.net>, Kees Cook <keescook@chromium.org>, Andi Kleen <andi@firstfloor.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>, linux-mm@kvack.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 0/3] Sanitizing freed pages Date: Tue, 19 May 2015 13:46:44 +0100 [thread overview] Message-ID: <20150519124644.GD2462@suse.de> (raw) In-Reply-To: <1431613188-4511-1-git-send-email-anisse@astier.eu> On Thu, May 14, 2015 at 04:19:45PM +0200, Anisse Astier wrote: > Hi, > > I'm trying revive an old debate here[1], though with a simpler approach than > was previously tried. This patch series implements a new option to sanitize > freed pages, a (very) small subset of what is done in PaX/grsecurity[3], > inspired by a previous submission [4]. > > There are a few different uses that this can cover: > - some cases of use-after-free could be detected (crashes), although this not > as efficient as KAsan/kmemcheck They're not detected, they're hidden. I'm currently seeing problems with a glibc update in userspace where applications are crashing because glibc returns buffers with uninitialised data that would previously have been zero. In every case so far, they were application bugs that need fixing. Having the kernel crash due to uninitialised memory use is bad but hiding it is not better. > - it can help with long-term memory consumption in an environment with > multiple VMs and Kernel Same-page Merging on the host. [2] This is not quantified but a better way of dealing with that problem would be for a guest to signal to the host when a page is really free. I vaguely recall that s390 has some hinting of this nature. While I accept there may be some benefits in some cases, I think it's a weak justification for always zeroing pages on free. > - finally, it can reduce infoleaks, although this is hard to measure. > It obscures them. That is leaving aside the fact that this has to be enabled at kconfig time which is unlikely to happen on a distribution config. Not many workloads depend on the freed path as such but streaming readers are one once the files are larger than memory. > The approach is voluntarily kept as simple as possible. A single configuration > option, no command line option, no sysctl nob. It can of course be changed, > although I'd be wary of runtime-configuration options that could be used for > races. > > I haven't been able to measure a meaningful performance difference when > compiling a (in-cache) kernel; I'd be interested to see what difference it > makes with your particular workload/hardware (I suspect mine is CPU-bound on > this small laptop). > What did you use to determine this and did you check if it was hitting the free paths heavily while it's running? It can be very easy to hide the cost of something like this if all the frees happen at exit. Overall, I'm not a big fan of this series. I think it would have made more sense to use non-temporal cleaning on pages if they are freed by kswapd or on a non-critical path like exit and then track if the page was already freed during allocation. Then add a runtime sysctl to make that strict and force all zeroing on all frees. As it is, I think it'll have very few users because of the need to enable it at kernel build time and then incur an unavoidable penalty. -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-05-19 12:46 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-05-14 14:19 [PATCH v4 0/3] Sanitizing freed pages Anisse Astier 2015-05-14 14:19 ` Anisse Astier 2015-05-14 14:19 ` Anisse Astier 2015-05-14 14:19 ` [PATCH v4 1/3] PM / Hibernate: prepare for SANITIZE_FREED_PAGES Anisse Astier 2015-05-14 14:19 ` Anisse Astier 2015-05-16 0:28 ` Rafael J. Wysocki 2015-05-16 0:28 ` Rafael J. Wysocki 2015-05-18 10:23 ` Anisse Astier 2015-05-18 10:23 ` Anisse Astier 2015-05-19 23:46 ` Rafael J. Wysocki 2015-05-19 23:46 ` Rafael J. Wysocki 2015-05-20 11:45 ` PaX Team 2015-05-20 11:45 ` PaX Team 2015-05-20 12:07 ` Anisse Astier 2015-05-20 12:07 ` Anisse Astier 2015-05-21 1:11 ` Rafael J. Wysocki 2015-05-21 1:11 ` Rafael J. Wysocki 2015-05-20 11:57 ` Anisse Astier 2015-05-20 11:57 ` Anisse Astier 2015-05-14 14:19 ` [PATCH v4 2/3] mm/page_alloc.c: add config option to sanitize freed pages Anisse Astier 2015-05-14 14:19 ` Anisse Astier 2015-05-18 11:21 ` Pavel Machek 2015-05-18 11:21 ` Pavel Machek 2015-05-18 12:41 ` Anisse Astier 2015-05-18 12:41 ` Anisse Astier 2015-05-18 13:02 ` Pavel Machek 2015-05-18 13:02 ` Pavel Machek 2015-05-18 13:04 ` Anisse Astier 2015-05-18 13:04 ` Anisse Astier 2015-05-19 1:58 ` yalin wang 2015-05-20 12:27 ` Anisse Astier 2015-05-20 12:27 ` Anisse Astier 2015-05-14 14:19 ` [PATCH v4 3/3] mm: Add debug code for SANITIZE_FREED_PAGES Anisse Astier 2015-05-14 14:19 ` Anisse Astier 2015-05-19 12:46 ` Mel Gorman [this message] 2015-05-19 12:46 ` [PATCH v4 0/3] Sanitizing freed pages Mel Gorman 2015-05-19 13:35 ` One Thousand Gnomes 2015-05-19 13:35 ` One Thousand Gnomes 2015-05-19 13:56 ` Mel Gorman 2015-05-19 13:56 ` Mel Gorman 2015-05-19 20:59 ` PaX Team 2015-05-19 20:59 ` PaX Team 2015-05-20 12:24 ` Anisse Astier 2015-05-20 12:24 ` Anisse Astier
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150519124644.GD2462@suse.de \ --to=mgorman@suse.de \ --cc=akpm@linux-foundation.org \ --cc=andi@firstfloor.org \ --cc=anisse@astier.eu \ --cc=gnomes@lxorguk.ukuu.org.uk \ --cc=keescook@chromium.org \ --cc=kirill.shutemov@linux.intel.com \ --cc=len.brown@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-pm@vger.kernel.org \ --cc=pageexec@freemail.hu \ --cc=pavel@ucw.cz \ --cc=peterz@infradead.org \ --cc=rientjes@google.com \ --cc=rjw@rjwysocki.net \ --cc=spender@grsecurity.net \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.