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

Message-ID: <2307239.2tnNighu20@vostro.rjw.lan>
Date:	Wed, 01 May 2013 00:38:17 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
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 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.

Thanks,
Rafael


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