linux-kernel - Re: [tip:x86/paravirt] x86-64, gdt: Store/ load GDT for ACPI S3 or hibernate/resume path is not needed.

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]

Date:	Tue, 30 Apr 2013 20:48:15 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	mingo@...nel.org, hpa@...or.com, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, hpa@...ux.intel.com,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/paravirt] x86-64, gdt: Store/ load GDT for ACPI S3 or
 hibernate/resume path is not needed.

On Wed, May 01, 2013 at 12:38:17AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, April 30, 2013 05:25:42 PM Konrad Rzeszutek Wilk wrote:
> > > > After the 'restore_registers' it returns and we end up called
> > > > restore_processor_state() - where we reload the GDT. The reload of
> > > > the GDT is not needed as bootup kernel has already loaded the GDT which
> > > > is at the same physical location as the the restored kernel.
> > > 
> > > I'm not sure if this particular statement is actually correct.  It is correct
> > > on 32-bit, but here it is not necessary for the bootup kernel to be the same
> > > as the image one.  Different kernel version may be used for that even (at
> > > least theoretically).  So the question is, and I'm quite unsure about the
> > > answer, if the GDT of from the bootup kernel is really *guaranteed* to be
> > > at the same location (given that those kernels may be really different).
> > 
> > A bit of testing with different bootup kernel provided me with this error:
> > PM: Image mismatch: version
> 
> This implies that you tested on an architechture without
> CONFIG_ARCH_HIBERNATION_HEADER.
> 
> > which after a bit of digging pointed me to 'check_image_kernel'. The criteria
> > there imply that the different kernel versions or releases cannot be used with
> > hibernation.
> 
> Only if CONFIG_ARCH_HIBERNATION_HEADER is unset, which is not the case for
> CONFIG_X86_64.

OK, Let me play on 64-bit later on this week and see if the patch I cobbled up
to save/restore the GDT in the booting kernel properly works.
--
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/