linux-ext4 - Re: [PATCH v2] mke2fs: warn about missing y2038 support when formatting fresh ext4 fs

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:   Fri, 13 Aug 2021 15:32:48 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     "Darrick J. Wong" <djwong@...nel.org>
Cc:     Andreas Dilger <adilger@...ger.ca>,
        linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH v2] mke2fs: warn about missing y2038 support when
 formatting fresh ext4 fs

On Fri, Aug 13, 2021 at 11:14:36AM -0700, Darrick J. Wong wrote:
> > There were only two cases where we created file systems with 128 byte
> > inodes --- "small" and "floppy" sized file systems, and for the GNU
> > Hurd, which only supports the original 128 byte inode.  What will GNU
> > Hurd do in 16.5 years?  ¯\_(ツ)_/¯
> 
> Perhaps in that time someone can donate a disused Opteron 140 system?
> Assuming the motherboard capacitors haven't since lost their mojo.

Apparently GNU Hurd uses a unsigned 32-bit int for time_t, so they
have a 2106 problem.  They "have no plans for a 64-bit userspace, but
they have plans for a 64-bit kernel that can run 32-bit user space".
Comments from the the GNU Hurd folks on an IRC chat from 2013:

    <braunr> which overflows in 2106
    <braunr> and we already include funny comments that predict our successors,
      if any, will probably fail to deal with the problem until short before
      the overflow :>
    <azeem> luckily, no nuclear reactors are running the Hurd sofar

    https://www.gnu.org/software/hurd/open_issues/versioning.html

> > +	/*
> > +	 * Warn the user that filesystems with 128-byte inodes will
> > +	 * not work properly beyond 2038.  This can be suppressed via
> > +	 * a boolean in the mke2fs.conf file, and we will disable this
> > +	 * warning for ext2, ext3, and hurd file systems.
> 
> Um... the conffile changes only disable the warning for Hurd?

Oops, good catch, I'll fix up the comment.

> > +This boolean relation specifies wheather mke2fs will issue a warning
> > +when creating a file system with 128 byte inodes (and so therefore will
> > +not support dates after January 19th, 2038.  The default value is true,
> 
> Nit: need a closing parentheses after '2038' or no opening paren.

Thanks, fixed.

> > +except for file systems created for the GNU Hurd, which does not support
> > +inodes larger than 128 bytes.
> 
> I wonder if this statementt about Hurd this belongs in the conffile as a
> comment in the hurd section?

We currently don't have a Hurd section.  We probably could document
more about the magic that mke2fs does when you specify "-o hurd",
which probably should go in the mke2fs man page but I can't quite
bring myself to care.  Maybe some GNU Hurd folks can get interested to
do this?  :-)

						- Ted