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: <20180419232715.GK23194@thunk.org>
Date:   Thu, 19 Apr 2018 19:27:15 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Matthew Wilcox <willy@...radead.org>
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 Thu, Apr 19, 2018 at 10:40:10AM -0700, Matthew Wilcox wrote:
> 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.

What you're talking about is a deployment issue, though.  Ultimately
the distribution will set up dm-removable automatically if the user
requests it, much like it sets up dm-crypt automatically for laptop
users upon request.

My concern is that not all removable devices have a globally unique id
number available in hardware so the kernel can tell whether or not
it's the same device that has been plugged in.  There are hueristics
you could use -- for example, you could look at the file system uuid
plus the last fsck time.  But they tend to be very file system
specific, and not things we would want ot have in the kernel.

					- Ted