public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oliver Neukum <oliver@neukum.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Andreas Steinmetz <ast@domdv.de>,
	Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] zero disk pages used by swsusp on resume
Date: Mon, 11 Apr 2005 12:37:45 +0200	[thread overview]
Message-ID: <200504111237.45452.oliver@neukum.org> (raw)
In-Reply-To: <20050410201455.GA21568@elf.ucw.cz>

Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
> Hi!
> 
> > > Oliver Neukum wrote:
> > > > What is the point in doing so after they've rested on the disk for ages?
> > > 
> > > The point is not physical access to the disk but data gathering after
> > > resume or reboot.
> > 
> > After resume or reboot normal access control mechanisms will work
> > again. Those who can read a swap partition under normal circumstances
> > can also read /dev/kmem. It seems to me like you are putting an extra
> > lock on a window on the third floor while leaving the front door open.
> 
> Andreas is right, his patches are needed.
> 
> Currently, if your laptop is stolen after resume, they can still data
> in swsusp image.
> 
> Zeroing the swsusp pages helps a lot here, because at least they are
> not getting swsusp image data without heavy tools. [Or think root
> compromise month after you used swsusp.]
> 
> Encrypting swsusp image is of course even better, because you don't
> have to write large ammounts of zeros to your disks during resume ;-).

Not only is it better, it completely supercedes wiping the image.
Your laptop being stolen after resume is very much a corner case.
You suspend your laptop while you are not around, don't you?

Additionally it helps only if you cannot trigger another swsusp, eg by
running dry the batteries.

	Regards
		Oliver

  parent reply	other threads:[~2005-04-11 10:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-10 13:13 [PATCH] zero disk pages used by swsusp on resume Andreas Steinmetz
2005-04-10 18:40 ` Oliver Neukum
2005-04-10 19:29   ` Andreas Steinmetz
2005-04-10 20:03     ` Oliver Neukum
2005-04-10 20:14       ` Pavel Machek
2005-04-11  3:23         ` Elladan
2005-04-11 10:14           ` Pavel Machek
2005-04-11  7:13         ` Stefan Seyfried
2005-04-11 10:37         ` Oliver Neukum [this message]
2005-04-11 16:39           ` Rafael J. Wysocki
2005-04-11 17:02             ` Andreas Steinmetz
2005-04-11 21:27               ` Rafael J. Wysocki
2005-04-12 10:08                 ` Andreas Steinmetz
2005-04-11 14:18         ` Jan Niehusmann
  -- strict thread matches above, loose matches on Subject: below --
2005-04-10 15:03 Pavel Machek
2005-04-10 15:15 ` [PATCH] " Andreas Steinmetz
2005-04-10 18:18   ` Pavel Machek
2005-04-10 18:45     ` Oliver Neukum
2005-04-10 18:56       ` Pavel Machek
2005-04-10 19:33     ` Andreas Steinmetz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200504111237.45452.oliver@neukum.org \
    --to=oliver@neukum.org \
    --cc=ast@domdv.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox