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: Fri, 1 Feb 2008 12:35:12 +0100 From: "Rafael J. Wysocki" <rjw@...k.pl> To: Michael Tokarev <mjt@....msk.ru> Cc: Pavel Machek <pavel@....cz>, Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: hibernate/suspend-to-disk: to turn power or not? On Friday, 1 of February 2008, Michael Tokarev wrote: > Pavel Machek wrote: > [] > >> I'm looking at the uswsusp source (while the kernel compiles), > >> and have a question here. Is it possible to call some external > >> application (typically a shell script) to do the final work after > >> when the image has been written? I mean in principle - I > >> understand there are some limitations here, but I don't know > >> which exactly. > > > > No, you can't exec() anything. That would write mtime back to disk and > > cause badness. > > Now that's.. interesting. > > s2disk writes to a swap device/file, which should update > mtime of this device node/file. Isn't it something which > also causes the same badness? No, please read the source carefully. We create a special tmpfs for that. > Also, if the only concern is mtime update, what's really > wrong with it? I mean, regardless of whether such update > will finally hit the disk or not, there's not much difference > really - it updates just mtime field, and there should be > no harm in that. Unless such update first goes to a > journal (in a journalling filesystem) - which DOES modify > some on-disk structures. Yes, we're concerned about the journaling. > >> it typically involves writing/reading something to/from > >> a given serial port (/dev/ttySxx), or to an USB device, > > > Create libups.so, and link s2disk to it? > > And what's the difference here again? We'll open a serial > port and write something to it - which, again, will update > mtime of that device node. Unless the said node is on a > tmpfs, exactly the same badness will happen. Not all the > world is udev, after all. We already have a tmpfs for that. > So I don't get the reason why we can't exec something here, > still. (And, for example, call splashy commands as external > processes, instead of linking all this cruft into s2disk and > resume.) > > What I'm thinking about here is - s2ram mlock()s its memory. > If it will fork/exec something, that something will obviously > NOT be locked like that. Is it of some concern? Probably > not, because that something will be executed after we've > taken the snapshot. Please don't exec() things from s2disk/s2both. Just link them to appropriate libraries and modify them to do things you need. Thanks, 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/
Powered by blists - more mailing lists