linux-kernel - Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump

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: <200709221240.25614.rjw@sisk.pl>
Date:	Sat, 22 Sep 2007 12:40:24 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Nigel Cunningham <nigel@...el.suspend2.net>
Cc:	Kyle Moffett <mrmacman_g4@....com>,
	Jeremy Maitin-Shepard <jbms@....edu>,
	Alan Stern <stern@...land.harvard.edu>, nigel@...pend2.net,
	Kexec Mailing List <kexec@...ts.infradead.org>,
	linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Huang, Ying" <ying.huang@...el.com>,
	linux-pm@...ts.linux-foundation.org,
	huang ying <huang.ying.caritas@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [linux-pm] Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump

On Saturday, 22 September 2007 01:47, Nigel Cunningham wrote:
> Hi.
> 
> On Saturday 22 September 2007 09:19:18 Kyle Moffett wrote:
> > I think that in order for this to work, there would need to be some  
> > ABI whereby the resume-ing kernel can pass its entire ACPI state and  
> > a bunch of other ACPI-related device details to the resume-ed kernel,  
> > which I believe it does not do at the moment.  I believe that what  
> > causes problems is the ACPI state data that the kernel stores is  
> > *different* between identical sequential boots, especially when you  
> > add/remove/replace batteries, AC, etc.
> 
> That's certainly possible. We already pass a very small amount of data between 
> the boot and resuming kernels at the moment, and it's done quite simply - by 
> putting the variables we want to 'transfer' in a nosave page/section.

Well, if the boot and image kernels are different, which is now possible on
x86_64 with some recent patches (currently in -mm), the nosave trick won't
work.

Still, I don't think we need to pass anything from the boot to the image
kernel.  Moreover, we shouldn't do that, IMO (arguably, the boot kernel
could be replaced with a resume-aware boot loader).

> I could  conceive of a scheme wherein this was extended for driver data.
> Since the memory needed would depend on the drivers loaded, it would
> probably require that the space be allocated when hibernating, and the
> locations of structures be stored in the image header and then drivers
> notified of the locations to use when preparing to resume, but it could
> work... 
>  
> > Since we currently throw away most of that in-kernel ACPI interpreter  
> > state data when we load the to-be-resumed image and replace it with  
> > the state from the previous boot it looks to the ACPI code and  
> > firmware like our system's hardware magically changed behind its  
> > back.  The result is that the ACPI and firmware code is justifiably  
> > confused (although probably it should be more idempotent to begin  
> > with).  There's 2 potential solutions:
> >    1) Formalize and copy a *lot* of ACPI state from the resume-ing  
> > kernel to the resume-ed kernel.
> >    2) Properly call the ACPI S4 methods in the proper order
> 
> ... that said, I don't think the above should be necessary in most cases. I 
> believe we're already calling the ACPI S4 methods in the proper order. If I 
> understood correctly, Rafael put a lot of effort into learning what that was, 
> and into ensuring it does get done.

Yes, I did, but I can be wrong nevertheless. ;-)

Greetings,
Rafael
-
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/