linux-kernel - Re: Linux 3.7-rc4

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]

Date:	Thu, 08 Nov 2012 15:06:14 +0000
From:	Nix <nix@...eri.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 3.7-rc4

On 4 Nov 2012, Linus Torvalds stated:

> Perhaps notable just because of the noise it caused in certain
> circles, there's the ext4 bitmap journaling fix for the issue that
> caused such a ruckus. It's a tiny patch and despite all the noise
> about it you couldn't actually trigger the problem unless you were
> doing crazy things with special mount options.

It also helps if you reboot during umount. Which is also crazy (says the
man who's still doing it). But the *real* problem is the way
journal_async_commit uses a journal checksum failure as an indication
that the commit was interrupted as long as there is no following commit
block, which as the comment in
fs/jbd2/recovery.c:do_one_pass():JBD2_COMMIT_BLOCK says, is going to
lead to an incorrect conclusion of interrupted commit and a successful
remount whenever commit N is corrupt and commit N+1 is interrupted (e.g.
by some loony rebooting or powerfailing during umount).

This problem seems to be intrinsic to journal_async_commit to me, since
it repurposes journal checksums to do a second job of missing-commit-
block detection, which pretty much means that *actual* checksum
failures, i.e. kernel bugs or corruption at writeout time, go
undetected, just as they do when journal checksumming is off -- but they
*also* mean that errors computing the checksum can go undetected. And
since journal checksumming is rarely used, such bugs can persist for a
relatively long time.

All of this means that journal_async_commit is *more* likely to cause a
no-warnings remount of a corrupted filesystem that really needs fscking
than is a filesystem using a normal non-checksummed journal. And that,
to me, is the really dangerous part. If you know the fs is corrupt, you
can fsck it and all is well, after a bit of flak: you won't overlook it.
If you don't know the fs is corrupt, you run a substantial risk of
making things much much worse before the problem escalates from ext4
errors in a log you never read into -EIO. (I happened to be reading that
log because I was trying to reproduce the nsm lockd bug. But normally?
Yeah, I spend all my time reading the kernel log, doesn't everyone?)

I'd apologise for causing all the fuss, but it wasn't me who decided to
submit it to Phoronix (actually I suspect Michael Larabel just read the
list and everything snowballed from there).

-- 
NULL && (void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/