linux-kernel - Re: [PATCH] x86/mm, hibernate: Fix misjudgment of register setup

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE9FiQX3jytdpoLS-Aoi6KhM9MSrW5-ffpvu-RRW4ccoQdbc_g@mail.gmail.com>
Date:	Fri, 30 Jan 2015 00:30:00 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	"Lee, Chun-Yi" <joeyli.kernel@...il.com>,
	Huang Ying <ying.huang@...el.com>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Ingo Molnar <mingo@...nel.org>, Pavel Machek <pavel@....cz>,
	Thomas Gleixner <tglx@...utronix.de>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Lee, Chun-Yi" <jlee@...e.com>, Len Brown <len.brown@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>, Takashi Iwai <tiwai@...e.de>
Subject: Re: [PATCH] x86/mm, hibernate: Fix misjudgment of register setup_data
 page to nosave region

On Thu, Jan 29, 2015 at 7:58 PM, Lee, Chun-Yi <joeyli.kernel@...il.com> wrote:
> The reserve setup_data action break usable regions to not align to
> page size. As following case:
>
> BIOS-e820: [mem 0x0000000000088000-0x00000000000bffff] reserved
> BIOS-e820: [mem 0x0000000000100000-0x0000000094caffff] usable
> ...
> e820: update [mem 0x93c5f018-0x93c6f057] usable ==> usable      /* reserve setup_data */
> e820: update [mem 0x93c4f018-0x93c5e057] usable ==> usable      /* reserve setup_data */
> ...
> reserve setup_data: [mem0x0000000000088000-0x00000000000bffff] reserved
> reserve setup_data: [mem0x0000000000100000-0x0000000093c4f017] usable /* not align */
> reserve setup_data: [mem0x0000000093c4f018-0x0000000093c5e057] usable /* not align */
> reserve setup_data: [mem0x0000000093c5e058-0x0000000093c5f017] usable /* not align */
> reserve setup_data: [mem0x0000000093c5f018-0x0000000093c6f057] usable /* not align */
> reserve setup_data: [mem0x0000000093c6f058-0x0000000094caffff] usable
>
> The codes in e820_mark_nosave_regions() check pfn of each e820
> entry to find out the hole between two entries then register it to
> nosave region. This logic misjudges the non-align but continuous usable
> region, then register one page in usable region to nosave. As following:
>
> PM: Registered nosave memory: [mem 0x000c0000-0x000fffff]
> PM: Registered nosave memory: [mem 0x93c4f000-0x93c4ffff] /* misjudgment */
> PM: Registered nosave memory: [mem 0x93c5e000-0x93c5efff] /* misjudgment */
> PM: Registered nosave memory: [mem 0x93c5f000-0x93c5ffff] /* misjudgment */
> PM: Registered nosave memory: [mem 0x93c6f000-0x93c6ffff] /* misjudgment */
> PM: Registered nosave memory: [mem 0x94cb0000-0x960affff]
>
> The issue causes some usable pages didn't collect to hibernate snapshot image.
> And, it also misjudges a usable page in nosave regions then hibernate resuming
> process interrupted by the unsafe pages checking:
>         https://bugzilla.opensuse.org/show_bug.cgi?id=913885
>
> This patch changed the code in e820_mark_nosave_regions() to check the
> address instead of pfn to avoid above issue.

[+cc: Ying Huang]

would like to suggest use attached instead:

Subject: [RFC PATCH] x86: Kill E820_RESERVED_KERN

Now we are using memblock to do early resource allocation instead of using
e820 map directly, and setup_data is reserved in memblock early.
Also kexec pass setup_data pointer to second kernel, so second kernel
will reserve setup_data by their own.

So we can kill E820_RESERVED_KERN and not touch e820 map at all.

That will fix bug in mark_nonsave_region that can not handle that
case: E820_RAM and E820_RESERVED_KERN continuous and boundary is
not page aligned.

Not sure about why tboot need to use this...

View attachment "kill_e820_reserved_kern.patch" of type "text/x-patch" (5940 bytes)