| 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
| ||
|
Message-ID: <87tzsew712.fsf@jbms.ath.cx> Date: Mon, 09 Jul 2007 00:11:21 -0400 From: Jeremy Maitin-Shepard <jbms@....edu> To: Al Boldi <a1426z@...ab.com> Cc: linux-kernel@...r.kernel.org Subject: Re: Hibernation Redesign Al Boldi <a1426z@...ab.com> writes: > Pavel Machek wrote: >> We are stuck with refrigerator for now, and at least for hibernation, >> I don't see any feasible alternative. > Feasible alternative? I posted such an alternative to the list a short time ago: hibenrating from a *new* kernel space/user space that is created by loading a new kernel in a manner similar to what is done for kexec crashdumps. Unlike kexec crashdumps, however, it would not require reserving any memory at boot, because the necessary memory (maybe 16MB or 64MB) can be freed just before hibernating, and device drivers can be properly stopped so that DMAs don't stomp over certain memory. This approach eliminates the need for the freezer, as it would make hibernate look a lot a bit like suspend to ram from the perspective of the "old" kernel (the kernel being hibernated), as the hibernate operation itself would be completely atomic from the perspective of the "old" kernel. That is not to say, of course, that any code paths would actually be shared, or that the drivers would do the same things (because they probably would not). [snip] -- Jeremy Maitin-Shepard - 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/
Powered by blists - more mailing lists