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
| ||
|
Message-ID: <1384070214.8994.47.camel@chiang> Date: Sun, 10 Nov 2013 02:56:54 -0500 From: David Turner <novalis@...alis.org> To: Mark Harris <mhlk@....us> Cc: Andreas Dilger <adilger@...ger.ca>, Jan Kara <jack@...e.cz>, Ext4 Developers List <linux-ext4@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Theodore Ts'o <tytso@....edu> Subject: Re: [PATCH] ext4: explain encoding of 34-bit a,c,mtime values On Sat, 2013-11-09 at 15:51 -0800, Mark Harris wrote: > > The problem with the existing encoding is that pre-1970 dates are > encoded with extra bits 1,1 in 64-bit kernels with ext4, but on 32-bit > kernels and inodes that were originally written as ext3 the extra bits > will be 0,0. Currently, both are decoded as pre-1970 dates. > > With your patch, only the 1,1 format used by 64-bit ext4 will decode > as a pre-1970 date. Dates previously written by ext3 or a 32-bit > kernel will no longer be decoded as expected. Also the patch does > not update ext4_encode_extra_time to use this format for pre-1970 > dates in 32-bit mode. You're right -- I missed the complexity here. > Possible solutions were discussed here, but no decision was made: > http://thread.gmane.org/gmane.comp.file-systems.ext4/26087/focus=26406 To summarize, the previous discussion offered four possible solutions, of which two were thought good: b. Use Andreas's encoding, which is incompatible with pre-1970 files written on 64-bit systems. c. Use an encoding which is compatible with all pre-1970 files, but incompatible with 64-bit post-2038 files, and which encodes a smaller range of time and is more complicated. ------- 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?). -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists