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: <CAK8P3a0dP+zvucn=_um1zRgBYQCskrhqa2KNSDtnpSu199baWw@mail.gmail.com>
Date:   Mon, 18 Jun 2018 17:49:25 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     y2038 Mailman List <y2038@...ts.linaro.org>,
        Tyler Baicar <tbaicar@...eaurora.org>,
        Will Deacon <will.deacon@....com>,
        Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
        Yazen Ghannam <yazen.ghannam@....com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        gengdongjiu <gengdongjiu@...wei.com>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] efi: cper: avoid using get_seconds()

On Mon, Jun 18, 2018 at 5:47 PM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> On 18 June 2018 at 16:17, Arnd Bergmann <arnd@...db.de> wrote:

>> -               atomic64_set(&seq, ((u64)get_seconds()) << 32);
>> +       if (!atomic64_read(&seq)) {
>> +               time64_t time = ktime_get_real_seconds();
>> +
>> +               /*
>> +                * This code is unlikely to still be needed in year 2106,
>> +                * but just in case, let's use a few more bits for timestamps
>> +                * after y2038 to be sure they keep increasing monotonically
>> +                * for the next few hundred years...
>> +                */
>> +               if (time < 0x80000000)
>> +                       atomic64_set(&seq, (ktime_get_real_seconds()) << 32);
>> +               else
>> +                       atomic64_set(&seq, 0x8000000000000000ull |
>> +                                          ktime_get_real_seconds() << 24);
>> +       }
>
> Given that these values are never decoded and interpreted as
> timestamps, can't we simply switch to the second flavour immediately?

I considered that, but the downside would be that all future filenames would
come before all past file names. I don't know if the order is important at
all, but the current implementation at least looks like it's intended to keep
all file names strictly sorted across boots.

         Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ