linux-ext4 - Re: Emergency remount readonly and EFBIG errors when unlinking files on 3.18 android kernel

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: <20160427030736.GB30021@thunk.org>
Date:	Tue, 26 Apr 2016 23:07:36 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Nikhilesh Reddy <reddyn@...eaurora.org>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Emergency remount readonly and EFBIG errors when unlinking files
 on 3.18 android kernel

On Tue, Apr 26, 2016 at 03:08:27PM -0700, Nikhilesh Reddy wrote:
> As you know Android uses emergency remount instead of doing something like
> "umount -a" in its shutdown/reboot path.

No, I didn't know that.  (And I wish I didn't.  Yelch, what an ugly
hack.)

> Teh issue doesnt happen all the writer processes are killed before the
> emergency remount

Is there a missing "if", as in "if all the writer processes".... ?

Note that an emergency remount is very much an emergency.  So we don't
do a graceful shutdown of any pending writes.  (Normally we would
return EBUSY if there anything that would prevent a clean remount.)
In the emergency remount path, we bypass all of these checks.

> And on disk we see that one of the files being written to has incorrect
> ext4_inode->i_blocks_lo ( which is less than the the size of the file by
> something like 2k)
> 
> When unlinking this file the vfs inode->iblocks underflows and we end up
> with EFBIG if EXT4_FEATURE_RO_COMPAT_HUGE_FILE is not enabled in the
> superblock.
> 
> Is this a known issue?

No, this isn't a known issue.  I've never seen anything like this, but
all of the tests we do assume a forced poweroff, which we simulate
using dm-flakey.  We do *not* test the blunt-force-trauma which is
inflected on the file system structures which results from doing an
emergency remount.

Off by 2k really doesn't make sense.  I could see if it was off by 4k,
but 2k is really wierd.

> I would appreciate if you could point me in the right direction and any help
> you can give me.

Well, what I'd do is create a new ioctl interface which simulates an
emergency ro on just the one device, and try to create a reliable
repro.  Eventually we'll want to add some tests for this in xfstests.

		   	      	     	  - Ted

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