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-next>] [day] [month] [year] [list]
Message-ID: <4546C637.5080504@comcast.net>
Date:	Mon, 30 Oct 2006 22:42:47 -0500
From:	John Richard Moser <nigelenki@...cast.net>
To:	linux-kernel@...r.kernel.org
Subject: Suspend to disk:  do we HAVE to use swap?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Something dumb came into my head, and the question is thus brought up
here:  Do we HAVE to use swap for suspend to disk? How about the file
system?

   [ Another thought I had here was where the word 'we' comes from; it
     seems habitual.  I'm not writing any of this code! ]

The first thought that came to my mind was:  The file system may not be
in a stable state.  If we don't use swap we're obviously using the FS;
so it has to be safe to mount.  Simple solution:  suspend to disk should
trigger the FS drivers to flush their state to disk and tie things off.
 Thus when we begin suspend things are suspended; the drivers know that
the only files to be created are the ones the kernel will make; and it's
safe for us to allocate space and make files, because we can read them
later.

This brings another thought:  If we use files, we have to do the above
so the disk can be mounted and read later.  This means the disk can be
mounted read-write by a LiveCD or other OS or whatever between--safely.
  So then, what do we do about changing files?  Files open and mmap()'d
are a huge problem if someone messes with them; solutions for this I do
not have, perhaps store the page cache as well.

So another thought:  What happens if we use the file system?  The kernel
goes and gets.. what?  Do we come up with the FS in read-only mode (from
an initrd or booting, either way) and have userspace tools tell the
kernel to resume from a given file?

And further, what if you change kernel versions?  Can we embed the
kernel version in the suspend image and get the kexec framework to load
that?  Have it bootstrap itself in and get to work resuming?

How about compressed images?  Can the suspend image be compressed as
it's stored, decompressed as it's read?

And, of course, WHY would you use a file on the file system instead of
swap?  This is probably the easiest and most straightforward question.
If you have 4 gigs of RAM, you might not want 4 gigs of swap.  Maybe you
have 256M of swap and 1 gig of ram.  Not much choice here.

Anyway, just random thoughts rolled out there in case anyone needs a
random seed.
- --
    We will enslave their women, eat their children and rape their
    cattle!
                  -- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBRUbGNgs1xW0HCTEFAQLaog//Z6c1KdRQxlc0B2GpRJSuyblVLBNmwK9n
IPMN+HA6c7u3EAiKq2PVVFUA1mhL/cyfnabG/p23sBKjdwZTodBDxMFw9y/SXa4k
g36mXsXOopZrUXmOJi0y0T/L96+iEzwr5Z++sMaybB5E9tsXKJiXmMwtEjc+HbEj
MW+ZGHTKcGqtei8OunvLkKSlCt3aaqwMWc5j3CM1gRODyShfY/NOeJTbGZG3fERB
25Gfa/KbCQVrgnhbyAyX+BggBkKHaw4tl6ari529JidkE1eie1O1zO8TlMi+rRmb
BgO6uZDWtZUTgKN662uamVHN5RvYW0QC1AqCDljKibQYZrtkoMN6AHZv+rp0z0G/
CcIld8ywgMOjcKK+8jKtYi9UUqkxgqIRH1IidRGgI7GKZqAqt357b6HTA2UxL59D
Gp0Z3/GgJqZBnb71wZLob/eTDC6hRzEmj7LJYZS//dYEkgD5aSA1NLulYuFoDEp5
eIOctN5GsHw0Gq90m/Oy24qPdgrm9J9wTE4eAEPLam3WKjZa9yo5Woq4lALwOda9
exsYDWzXD/EXekVM648673igfnZvcqN9lGavpfwOJaAIaMYKPX55suk1Kp9ZbFVQ
Wl1cBGmQ1Dpnlf6M0BVLi3jyUsUJy2AH/hRGhIYL+r8DzlffNI5ibLuCyMfoKwge
jMx6FuzqBKk=
=hpQy
-----END PGP SIGNATURE-----
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ