linux-kernel - Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

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]

Date:	Thu, 28 Jul 2016 01:20:53 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
Cc:	"Rafael J. Wysocki" <rafael@...nel.org>,
	Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
	Pavel Machek <pavel@....cz>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>, shuzzle@...lbox.org
Subject: Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

On Wednesday, July 27, 2016 05:17:38 PM Josh Poimboeuf wrote:
> On Thu, Jul 28, 2016 at 12:12:15AM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, July 27, 2016 12:59:18 PM Josh Poimboeuf wrote:
> > > Hm... I have a theory, but I'm not sure about it.  I noticed that
> > > x86_acpi_enter_sleep_state(),
> > 
> > I think you mean x86_acpi_suspend_lowlevel().
> 
> Oops!
> 
> > > which is involved in suspend, overwrites
> > > several global variables (e.g, initial_code) which are used by the CPU
> > > boot code in head_64.S.  But surprisingly, it doesn't restore those
> > > variables to their original values after it resumes.
> > 
> > Is the head_64.S code also used to bring up offline CPUs?
> 
> Yes.

OK

So it is really interesting why and how that stuff works for everybody.

Basically, CPU online should fail after a suspend-resume cycle, but it
doesn't most of the time AFAICS.

> > If not, then this is not the problem, because hibernation doesn't use it
> > for the boot CPU anyway.
> > 
> > > So if a suspend and resume were done before the hibernate, those
> > > variables would presumably have suspend-centric values, and the first
> > > time a CPU is brought up during the hibernation restore operation, it
> > > would jump to wakeup_long64() (the suspend resume function) instead of
> > > start_secondary (which is the normal CPU boot function).
> > > 
> > > So, if true, that would explain why my patch triggers a bug:
> > > wakeup_long64() always[*] jumps to .Lresume_point, which my patch
> > > affected.  Because of the FRAME_END, it would pop an extra value off the
> > > stack.  So when restore_processor_state() returns, it would return to
> > > whatever random address is on the stack after the real RIP.  Which is
> > > consistent with the oops from the bug.  It had a bad instruction
> > > pointer, which looked like a stack address.
> > 
> > OK, so why doesn't it break resume from suspend to RAM?
> 
> Because for suspend to RAM, it enters suspend through
> do_suspend_lowlevel(), which has the FRAME_BEGIN which corresponds to
> .Lresume_point's FRAME_END.
> 
> > wakeup_long64 is invoked by the CPU startup code then and doesn't the
> > FRAME_END affect that too?
> 
> Yes, I would imagine that any CPU startup operation (after
> suspend/resume to RAM) would be affected.

That would mean that your patch is needed anyway, wouldn't it?

Thanks,
Rafael