linux-ext4 - Re: [PATCH] vfs: freeze filesystems just prior to reboot

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:   Tue, 23 May 2017 13:10:07 +0200
From:   Jan Kara <jack@...e.cz>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Colin Walters <walters@...bum.org>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        xfs <linux-xfs@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] vfs: freeze filesystems just prior to reboot

On Fri 19-05-17 11:27:34, Ted Tso wrote:
> The other thing that would be useful is if grub2 would actually be
> able to replay the file system journal --- but given that grub2 is
> GPLv3, and both ext4 and xfs are GPLv2-only, and given that past
> attempts of teams attempting to do clean room reimplementations of
> complex code bases for licensing reasons only (cough, make_ext4fs,
> *cough*) have not necessarily turned out well, I'm at least not going
> to hold my breath.

Boot loader really should *not* write to the filesystem. Firstly, it would
have to be completely separate codebase running under very different
constraints (real mode, no real memory management, etc) so there's no easy
way to share the code with any other userspace libraries and thus the code
will be inherently buggy. Secondly, think of stuff like suspend to disk -
if someone touches the filesystem in any way under the hands of suspended
kernel, file system corruption is very likely to follow sooner or later.
Just last year, I've spent couple of interesting days hunting down ext4
corruption on s390 only to find out that the boot procedure(*) there ended
up replaying the journal under suspended kernel...

(*) Just for the ones interested in mainframe woes: s390 in SLES doesn't
use grub to parse the filesystem (as it is too difficult to access some
storage types from the boot loader AFAIU) so it uses "first-stage" Linux
kernel to mount the root filesystem, finds proper kernel image there and
then kexecs into it...

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