linux-ext4 - Re: fsync() errors is unsafe and risks data loss

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: <20180419174010.GA5891@bombadil.infradead.org>
Date:   Thu, 19 Apr 2018 10:40:10 -0700
From:   Matthew Wilcox <willy@...radead.org>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Dave Chinner <david@...morbit.com>,
        Jeff Layton <jlayton@...hat.com>,
        lsf-pc <lsf-pc@...ts.linuxfoundation.org>,
        Andres Freund <andres@...razel.de>,
        Andreas Dilger <adilger@...ger.ca>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        "Joshua D. Drake" <jd@...mandprompt.com>
Subject: Re: fsync() errors is unsafe and risks data loss

On Wed, Apr 18, 2018 at 09:08:19PM -0400, Theodore Y. Ts'o wrote:
> On Wed, Apr 18, 2018 at 05:40:37PM -0700, Matthew Wilcox wrote:
> > 
> > I've been thinking about this.  Ideally we want to pass some kind of
> > notification all the way up to the desktop and tell the user to plug the
> > damn stick back in.  Then have the USB stick become the same blockdev
> > that it used to be, and complete the writeback.  We are so far from
> > being able to do that right now that it's not even funny.o
> 
> Maybe we shouldn't be trying to do any of this in the kernel, or at
> least as little as possible in the kernel?  Perhaps it would be better
> to do most of this as a device mapper hack; I suspect we'll need
> userspace help to igure out whether the user has plugged the same USB
> stick in, or a different USB stick, anyway.

The device mapper target (dm-removable?) was my first idea too, but I kept
thinking through use cases and I think we end up wanting this functionality
in the block layer.  Let's try a story.

Stephen the PFY goes into the data centre looking to hotswap a failed
drive.  Due to the eight pints of lager he had for lunch, he pulls out
the root drive instead of the failed drive.  The air raid siren warbles
and he realises his mistake, shoving the drive back in.

CYOA:

Currently: All writes are lost, calamities ensue.  The PFY is fired.

With dm-removable: Nobody thought to set up dm-removable on the root
drive.  Calamities still ensue, but now it's the BOFH's fault instead
of the PFY's fault.

Built into the block layer: After a brief hiccup while we reattach the
drive to its block_device, the writes resume and nobody loses their job.