linux-ext4 - Re: [PATCH] ext4: do not update s_last

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:   Mon, 23 Apr 2018 01:50:15 +0200
From:   Jan Kara <jack@...e.cz>
To:     Amir Goldstein <amir73il@...il.com>
Cc:     Jan Kara <jack@...e.cz>, Theodore Tso <tytso@....edu>,
        Ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] ext4: do not update s_last_mounted of a frozen fs

On Mon 23-04-18 02:16:19, Amir Goldstein wrote:
> On Mon, Apr 23, 2018 at 1:57 AM, Jan Kara <jack@...e.cz> wrote:
> > On Sun 22-04-18 09:12:10, Amir Goldstein wrote:
> >> If fs is frozen after mount and before the first file open, the
> >> update of s_last_mounted bypasses freeze protection and prints out
> >> a WARNING splat:
> >>
> >> $ mount /vdf
> >> $ fsfreeze -f /vdf
> >> $ cat /vdf/foo
> >>
> >> [   31.578555] WARNING: CPU: 1 PID: 1415 at
> >> fs/ext4/ext4_jbd2.c:53 ext4_journal_check_start+0x48/0x82
> >>
> >> [   31.614016] Call Trace:
> >> [   31.614997]  __ext4_journal_start_sb+0xe4/0x1a4
> >> [   31.616771]  ? ext4_file_open+0xb6/0x189
> >> [   31.618094]  ext4_file_open+0xb6/0x189
> >>
> >> This fix might not be free of open vs. freeze race, but it closes
> >> a big hole.
> >>
> >> [backport hint: to apply to stable tree, just need to repace
> >>                 sb_rdonly(sb) with (sb->s_flags & MS_RDONLY)]
> >>
> >
> > Thanks for the patch. But a proper (race-free) fix for this is to use
> > sb_start_intwrite(), before starting a handle and sb_end_intwrite() after
> > stopping it.
> >
> 
> The thing is, it doesn't make sense reading a file will block because
> fs is frozen, does it? So a proper fix would probably involve a new
> helper sb_start_intwrite_trylock(), but I wasn't sure exactly, so posted
> this naiive version. So do you think sb_start_intwrite_trylock()
> would be good here?

Yeah, better than your racy check... ;)

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR