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: <20170523111007.GH1230@quack2.suse.cz>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ