Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751889AbbESVBc (ORCPT ); Tue, 19 May 2015 17:01:32 -0400 Received: from r00tworld.com ([212.85.137.150]:54883 "EHLO r00tworld.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751261AbbESVB3 (ORCPT ); Tue, 19 May 2015 17:01:29 -0400 From: "PaX Team" To: Anisse Astier , Mel Gorman Date: Tue, 19 May 2015 22:59:16 +0200 MIME-Version: 1.0 Subject: Re: [PATCH v4 0/3] Sanitizing freed pages Reply-to: pageexec@freemail.hu CC: Andrew Morton , "Kirill A. Shutemov" , David Rientjes , Alan Cox , Linus Torvalds , Peter Zijlstra , Brad Spengler , Kees Cook , Andi Kleen , "Rafael J. Wysocki" , Pavel Machek , Len Brown , linux-mm@kvack.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Message-ID: <555BA424.2410.2365DFC8@pageexec.freemail.hu> In-reply-to: <20150519124644.GD2462@suse.de> References: <1431613188-4511-1-git-send-email-anisse@astier.eu>, <20150519124644.GD2462@suse.de> X-mailer: Pegasus Mail for Windows (4.70) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.12 (r00tworld.com [212.85.137.150]); Tue, 19 May 2015 22:59:20 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2074 Lines: 45 On 19 May 2015 at 13:46, Mel Gorman wrote: > 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. this is a qualitative argument that cuts both ways. namely, you could say that uninitialized memory does *not* trigger any bad behaviour exactly because the previous content acts as valid data (say, a valid pointer) whereas a null dereference would pretty much always crash (both in userland and the kernel). not to mention that a kernel null deref is no longer an exploitable bug in many/most situations which can't be said of arbitrary uninitialized (read: potentially attacker controlled) values. that said, i always considered this aspect of page sanitization as a (potentially useful) side effect, not the design goal. > > - finally, it can reduce infoleaks, although this is hard to measure. > > > > It obscures them. i don't understand, what is being obscured exactly? maybe the term 'infoleaks' is ambiguous, in case of page sanitization it refers to the reduction of data lifetime (mostly userland anonymous memory, as per the original design). if you were thinking of kernel->userland kind of leaks then i'd say that page sanitization has little effect there because all the bugs i can think of were not leaking from freed memory (where sanitization would have prevented the leak). -- 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/