linux-ext4 - Re: [PATCH] bootfs: simple bootloader filesystem

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: <E2E8A5E4-D174-4E90-8D8F-F1D69E98F20E@dilger.ca>
Date:   Tue, 2 Apr 2019 15:52:59 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>
Cc:     Dave Chinner <david@...morbit.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-ext4 <linux-ext4@...r.kernel.org>,
        xfs <linux-xfs@...r.kernel.org>
Subject: Re: [PATCH] bootfs: simple bootloader filesystem

On Apr 1, 2019, at 10:55 PM, Darrick J. Wong <darrick.wong@...cle.com> wrote:
> 
> On Tue, Apr 02, 2019 at 08:46:32AM +1100, Dave Chinner wrote:
>> On Mon, Apr 01, 2019 at 12:00:01AM -0700, Darrick J. Wong wrote:
>>> From: Darrick J. Wong <djwong@...nel.org>
>>> 
>>> Does your computer use a bootloader which arrogantly declares that it can
>>> read boot files off a filesystem but isn't sophisticated enough even to
>>> recognize when that filesystem needs journal recovery?
>>> 
>>> Does your system software deployment program foolishly omit system calls
>>> to flush newly unwrapped packages to disk?  Do you sometimes wonder if
>>> they've forgotten that old maxim, "wait for the disk drive light to turn
>>> off /before/ you power down"?
>>> 
>>> Are your computer operators aggressively derpy?  Do they have a habit of
>>> leaving disk cables on the floor so they can trip over them twenty times
>>> a day?  Does this leave you with sad files full of zeroes?
>>> 
>>> If so, bootfs is for you!  This new filesystem type uses journalling to
>>> ensure metadata integrity, but forces all writes and directory tree
>>> updates to be synchronous, fsyncs files on close, and checkpoints its
>>> journal whenever a synchronization event happens.  Some allege this is
>>> very slow, but I've been able to max out the iops on both of my double
>>> height floppy drives!  In a power-cycling stress test, I found that the
>>> switch broke off in my hand before I lost any data.  This concept may
>>> sound terrible, but like any good crutch, it _is_ made of wood!
>>> 
>>> Singed-off-by: Darrick J. Wong <djwong@...nel.org>
>>  ^^^^^^^^^^
>> 
>> Ooooo - such a hot topic! Finally bootfs is more than just
>> we-really-should-do-this conference talk!
>> 
>> Looks good to me - with this we can finally move on from LILO....
> 
> When Ted is done laughing, I really would like to consider something
> like this to solve the problem of grub-style bootloaders requiring a
> lease on the blocks underneath a file with a term exceeding that of the
> running kernel.
> 
> We can probably skip the harsh synchronous writes in favor of fsync on
> close, but we would need to keep the critical component of checkpointing
> the journal on fsync and syncfs.

Wouldn't it be enough if Grub marked the file IMMUTABLE so that it didn't
get remapped/rewritten?  The RPM pre/post kernel update scripts already
have hooks to rerun grub and update /etc/grub.conf, so they should also
be able to handle set/clear of the immutable flag during upgrade.

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)