linux-kernel - Re: [PATCH v9 09/13] exfat: add misc operations

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: <CAK8P3a0S6DBJqDMj4Oy9xeYVhW87HbBX2SqURFPKYT8K1z7fDw@mail.gmail.com>
Date:   Wed, 8 Jan 2020 20:40:53 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Christoph Hellwig <hch@....de>
Cc:     Pali Rohár <pali.rohar@...il.com>,
        Namjae Jeon <namjae.jeon@...sung.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        gregkh <gregkh@...uxfoundation.org>,
        Valdis Kletnieks <valdis.kletnieks@...edu>,
        sj1557.seo@...sung.com, linkinjeon@...il.com
Subject: Re: [PATCH v9 09/13] exfat: add misc operations

On Wed, Jan 8, 2020 at 7:03 PM Christoph Hellwig <hch@....de> wrote:
>
> Arnd, can you review the exfat time handling, especially vs y2038
> related issues?

Sure, thanks for adding me to the loop

> On Thu, Jan 02, 2020 at 10:19:02AM +0100, Pali Rohár wrote:
> > On Thursday 02 January 2020 16:20:32 Namjae Jeon wrote:
> > > +#define TIMEZONE_CUR_OFFSET()      ((sys_tz.tz_minuteswest / (-15)) & 0x7F)
> > > +/* Convert linear UNIX date to a FAT time/date pair. */
> > > +void exfat_time_unix2fat(struct exfat_sb_info *sbi, struct timespec64 *ts,
> > > +           struct exfat_date_time *tp)
> > > +{
> > > +   time_t second = ts->tv_sec;
> > > +   time_t day, month, year;
> > > +   time_t ld; /* leap day */
> >
> > Question for other maintainers: Has kernel code already time_t defined
> > as 64bit? Or it is still just 32bit and 32bit systems and some time64_t
> > needs to be used? I remember that there was discussion about these
> > problems, but do not know if it was changed/fixed or not... Just a
> > pointer for possible Y2038 problem. As "ts" is of type timespec64, but
> > "second" of type time_t.

I am actually very close to sending the patches to remove the time_t
definition from the kernel, at least in yesterday's version there were no
users.

exfat_time_unix2fat() seems to be a copy of the old fat_time_unix2fat()
that we fixed a while ago, please have a look at that implementation
based on time64_to_tm(), which avoids time_t.

      Arnd