linux-kernel - Re: [PATCH v4 1/3] PM / Hibernate: prepare for SANITIZE_FREED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4282804.3atZjAcjTt@vostro.rjw.lan>
Date:	Thu, 21 May 2015 03:11:12 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Anisse Astier <anisse@...ier.eu>
Cc:	PaX Team <pageexec@...email.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	David Rientjes <rientjes@...gle.com>,
	Alan Cox <gnomes@...rguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Brad Spengler <spender@...ecurity.net>,
	Kees Cook <keescook@...omium.org>,
	Andi Kleen <andi@...stfloor.org>, Pavel Machek <pavel@....cz>,
	Len Brown <len.brown@...el.com>, linux-mm@...ck.org,
	Linux PM list <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 1/3] PM / Hibernate: prepare for SANITIZE_FREED_PAGES

On Wednesday, May 20, 2015 02:07:36 PM Anisse Astier wrote:
> On Wed, May 20, 2015 at 1:45 PM, PaX Team <pageexec@...email.hu> 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.

Well, that is not a matter of opinion really, but it's actually correct.

> 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.

Correct, except that some of the boot kernel's memory will be overwritten
by the image kernel and all.

> Rafael, am I getting something wrong on the hibernation resume process
> ? What do you think of this analysis ?

That's more-or-less what's happening.  IOW, after hibernation and resume you
may see stuff in pages that were previously all zeros as long as they are
regarded as free by the image kernel.  The stuff in there is all garbage from
its perspective though.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/