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

Message-ID: <20130514185754.GF2041@belle.intranet.vanheusden.com>
Date:	Tue, 14 May 2013 20:57:54 +0200
From:	folkert <folkert@...heusden.com>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: checksums

> > 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.

> > > 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?

> (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