linux-ext4 - Re: Remounting filesystem read-only

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:   Sat, 28 Jul 2018 00:47:04 -0700
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>,
        Sodagudi Prasad <psodagud@...eaurora.org>,
        adilger.kernel@...ger.ca, wen.xu@...ech.edu,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Remounting filesystem read-only

On Fri, Jul 27, 2018 at 08:18:23PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 27, 2018 at 01:34:31PM -0700, Sodagudi Prasad wrote:
> > > The error should be pretty clear: "Inode table for bg 0 marked as
> > > needing zeroing".  That should never happen.
> > 
> > Can you provide any debug patch to detect when this corruption is happening?
> > Source of this corruption and how this is partition getting corrupted?
> > Or which file system operation lead to this corruption?
> 
> Do you have a reliable repro?  If it's a one-off, it can be caused by
> *anything*.  Crappy hardware, a bug in some proprietary, binary-only
> GPU driver dereferencing some wild pointer that corrupts kernel
> memory, etc.
> 
> Asking for a debug patch is like asking for "can you create technology
> that can detect when a cockroach enter my house?"

Well, ext4 *could* add metadata read and write verifiers to complain
loudly in dmesg about stuff that shouldn't be there, so at least we'd
know when we're writing cockroaches into the house... :)

--D

> So if you have a reliable repro, then we know what operations might be
> triggering the corruption, and then you work on creating a minimal
> repro, and only *then* when we have a restricted set of possibilities
> that might be the cause (for example, if removing a GPU call makes the
> problem go away, then the patch would need to be in the proprietary
> GPU driver....)
> 
> > I am digging code a bit around this warning to understand more.
> 
> The warning means that a flag in block group descriptor #0 is set
> that should never be set.  How did the flag get set?  There is any
> number of things that could cause that.
> 
> You might want to look at the block group descriptor via dumpe2fs or
> debugfs, to see if it's just a single bit getting flipped, or if the
> entire block group descriptor is garbage.  Note that under normal code
> paths, the flag *never* gets set by ext4 kernel code.  The flag will
> get set on non-block group 0 block group descriptors by ext4, and the
> ext4 kernel code will only clear the flag.
> 
> Of course, if there is a bug in some driver that dereferences a
> pointer widely, all bets are off.
> 
> 					- Ted