linux-ext4 - Re: checksums

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] [day] [month] [year] [list]

Date:	Tue, 14 May 2013 12:21:43 -0700
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	folkert <folkert@...heusden.com>
Cc:	"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: checksums

On Tue, May 14, 2013 at 08:57:54PM +0200, folkert wrote:
> > > Ok. But that would only when the filesystem is not mounted.
> > > Maybe some on-line functionality for doing so would be nice. I'm not
> > > totally aware of the filesystem structures in memory/on disk, but
> > > reading meta-data from disk which has changes pending in memory/in the
> > > journal would give at worst a verify of old(er) data. I don't think this
> > > (checking occasional old data) is a bad thing - scrubbing a
> > > raid-device/disk doesn't give you the situation for the whole disk(s) in
> > > 1 (!) point at time either. If that would be required, then the user
> > > could still unmount the filesystem and do a check.
> > 
> > Well... if you ran filefrag -v on every file on the disk and read all the
> > xattrs, you'd scrub nearly all the metadata.  The only things you'd miss are
> > unallocated parts of the disk, most of which e2fsck also skips.
> 
> Yes but that is, imho, a bit dirty method.
> Because I assume the result will be a message in dmesg and the
> filesystem being remounted r/o?
> I think it would be better if a nice message on the user's terminal and
> an exit code.

You should see "I/O Error" (or whatever -EIO becomes in the message catalog) on
the terminal running filefrag if you hit a checksum error, in addition to a
complaint in dmesg and a ro fs.

> > > > That's not currently on the development roadmap; I could imagine
> > > > someone deciding to design an extension to ext4 that would do this
> > > > probably by storing the checksums in the indirect blocks, but no one
> > > > is currently working on it.
> > 
> > sha256sum < file > file.sha256 ? :D
> 
> Then you would need to read the whole file. I think it would be better
> to have this on e.g. block-level. 4KB so CRC32 suffices?

block or bigalloc-cluster level, I suppose.

--D
> 
> > (If only there was disk space and brain-time to do something where you could
> > *reconstruct* data.)
> 
> ah yes.
> These days everything is done by the gpu, maybe it can help with that :)
> 
> 
> Folkert van Heusden
> 
> -- 
> www.vanheusden.com/multitail - multitail is tail on steroids. multiple
>                windows, filtering, coloring, anything you can think of
> ----------------------------------------------------------------------
> Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html