| 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
| ||
|
Date: Sun, 8 Jul 2007 17:37:21 +0300 From: Al Boldi <a1426z@...ab.com> To: linux-kernel@...r.kernel.org Subject: Hibernation Redesign (was: malicious filesystems (was Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM) Pavel Machek wrote: > We are stuck with refrigerator for now, and at least for hibernation, > I don't see any feasible alternative. Feasible alternative? Freezing is the only way to successfully suspend, in kernel space that is. The problem here is: Why do we freeze in kernel space? APM didn't freeze in kernel space, and neither should ACPI. The only reason you would want to freeze in kernel space is because your system does not have APM or ACPI or anything else to freeze from BIOS level. So the problem is really easy to solve: either call the APM suspend functions or install ACPI soft-extensions to implement hibernation from BIOS level. But there is a catch: Hibernation from BIOS level probably requires a diskdriver, which isn't always available from BIOS level or is really slow. So you are back to freezing in kernel space, but this time you know why, and that you need a system that simply halts to disk after issuing sync-out requests to all peripheral devices involved. Which sounds like the freezer in mainline, does it not? And if it does, then what's the problem? Thanks! -- Al - 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