Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752638AbbETMIC (ORCPT ); Wed, 20 May 2015 08:08:02 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:34785 "EHLO mail-wg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751555AbbETMH6 (ORCPT ); Wed, 20 May 2015 08:07:58 -0400 MIME-Version: 1.0 In-Reply-To: <555C73E7.23237.269170A5@pageexec.freemail.hu> References: <1431613188-4511-1-git-send-email-anisse@astier.eu> <1526358.9aMpXL2Hv2@vostro.rjw.lan> <555C73E7.23237.269170A5@pageexec.freemail.hu> From: Anisse Astier Date: Wed, 20 May 2015 14:07:36 +0200 Message-ID: Subject: Re: [PATCH v4 1/3] PM / Hibernate: prepare for SANITIZE_FREED_PAGES To: PaX Team , "Rafael J. Wysocki" Cc: Andrew Morton , Mel Gorman , "Kirill A. Shutemov" , David Rientjes , Alan Cox , Linus Torvalds , Peter Zijlstra , Brad Spengler , Kees Cook , Andi Kleen , Pavel Machek , Len Brown , linux-mm@kvack.org, Linux PM list , 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: 1958 Lines: 40 On Wed, May 20, 2015 at 1:45 PM, PaX Team wrote: > >> Moreover, why is the resume code path the only one where freed pages need to >> be sanitized? > > ... i had a bug report before (http://marc.info/?l=linux-pm&m=132871433416256) > which is why i asked Anisse to figure this out before upstreaming the feature. > i've also asked him already to explain why his approach is the proper fix for > the problem (which should include the description of the root cause as a start) > but he hasn't answered that yet. > > anyway, the big question is how there can be free memory pages after resume > which are not sanitized. now i have no idea about the hibernation logic but > i assume that it doesn't save/restore free pages so the question is how the > kernel gets to learn about these free pages during resume and whether there's > a path where __free_page() or some other wrapper around free_pages_prepare() > doesn't get called at all. In my opinion the free pages left are those used by the loading kernel. If I understand correctly, a suspend (hibernate) image contains *all* the memory necessary for the OS to work; so when you restore it, you restore it all, page tables, and kernel code section included. So when the kernel does a hibernate restoration, it loads it all the pages into memory, then architecture-specific code will jump into the new "resumed" kernel by restoring page table entries and CPU context. When it does that, it leaves the "loader" kernel memory hanging; this memory is seen as free pages by the resumed kernel, but it isn't cleared. Rafael, am I getting something wrong on the hibernation resume process ? What do you think of this analysis ? Regards, 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/