linux-ext4 - Re: [PATCH] ext4: explain encoding of 34-bit a,c,mtime values

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, 12 Nov 2013 14:35:04 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	Theodore Ts'o <tytso@....edu>
Cc:	David Turner <novalis@...alis.org>, Mark Harris <mhlk@....us>,
	Jan Kara <jack@...e.cz>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ext4: explain encoding of 34-bit a,c,mtime values

On Nov 11, 2013, at 5:30 PM, Theodore Ts'o <tytso@....edu> wrote:
> On Sun, Nov 10, 2013 at 02:56:54AM -0500, David Turner wrote:
>> b. Use Andreas's encoding, which is incompatible with pre-1970 files
>> written on 64-bit systems.
>> 
>> I don't care about currently-existing post-2038 files, because I believe
>> that nobody has a valid reason to have such files.  However, I do
>> believe that pre-1970 files are probably important to someone.
>> 
>> Despite this, I prefer option (b), because I think the simplicity is
>> valuable, and because I hate to give up date ranges (even ones that I
>> think we'll "never" need). Option (b) is not actually lossy, because we
>> could correct pre-1970 files with e2fsck; under Andreas's encoding,
>> their dates would be in the far future (and thus cannot be legitimate).
>> 
>> Would a patch that does (b) be accepted?  I would accompany it with a
>> patch to e2fsck (which I assume would also go to the ext4 developers
>> mailing list?).
> 
> I agree, I think this is the best way to go.  I'm going to drop your
> earlier patch, and wait for an updated patch from you.  It may miss
> this merge window, but as Andreas has pointed out, we still have a few
> years to get this right.  :-)

Since this change would immediately break files encoded with pre-1970 dates
on ext4 filesystems, should there be a transition period where both pre-1970
dates (with extra epoch bits == 0x3 in the current encoding) and post-2378
(with extra epoch bits == 0x3 in the new encoding) are decoded as being
pre-1970?  That could be conditional until some release in the future (e.g.
>= Linux 4.20, at least 5 years away) to give folks a chance to run the new
e2fsck to fix up those files.

Are there really any ext4 filesystems that have files with valid dates so old?
I don’t want to break anyone’s data, but if this extra complexity is completely
pointless then I’m also fine with this minor risk of breakage.

Cheers, Andreas






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