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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9885.1305905687@localhost>
Date:	Fri, 20 May 2011 11:34:47 -0400
From:	Valdis.Kletnieks@...edu
To:	"D. Jansen" <d.g.jansen@...glemail.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, tytso@....edu
Subject: Re: [rfc] Ignore Fsync Calls in Laptop_Mode

On Thu, 19 May 2011 17:02:21 +0200, "D. Jansen" said:
> On Thu, May 19, 2011 at 3:43 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> > That at least cuts down most failures (but not all - eg commits with a network
> > component such as email receives)
>
> I don't understand your email example.

If you don't understand Alan's example, maybe you shouldn't be messing with
code that's used for correctness guarantees.  But I'll spell it out for you:

You turn on laptop mode.  You check your mail.  You download 5 new messages,
which your laptop then *assures* the mail server "I've got them, we're cool".
Now, this is a pretty heavy responsibility (for example, RFC2821 says this:

6.1 Reliable Delivery and Replies by Email

   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
   message in response to DATA), it is accepting responsibility for
   delivering or relaying the message.  It must take this responsibility
   seriously.  It MUST NOT lose the message for frivolous reasons, such
   as because the host later crashes or because of a predictable
   resource shortage.

So - the mail server then deletes the mail because the laptop has told it "Yes,
I've gotten it, it's stable, and even if I crash I won't lose it".  But since
the mail program's fsync() calls got suppressed, it really *isn't* stable, so
when you crash, the mails are gone. Poof.

Second order effects crop up after that - after you recover from the crash,
your end has no memory of downloading the 5 messages, so it tries again - only
to have the mail server say "No such message".  This is the sort of inconsistency
that gives guys at the support desk indigestion...

Understand better now?


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ