linux-kernel - Re: [PATCH 1/3] [v2] powerpc: mac: fix rtc read/write functions

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: <alpine.LNX.2.21.1807101105130.12@nippy.intranet>
Date:   Tue, 10 Jul 2018 11:18:34 +1000 (AEST)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Arnd Bergmann <arnd@...db.de>
cc:     Meelis Roos <mroos@...ux.ee>, Mathieu Malaterre <malat@...ian.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Joshua Thompson <funaho@...ai.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Greg Ungerer <gerg@...ux-m68k.org>, linux-m68k@...r.kernel.org,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        LKML <linux-kernel@...r.kernel.org>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Andreas Schwab <schwab@...ux-m68k.org>
Subject: Re: [PATCH 1/3] [v2] powerpc: mac: fix rtc read/write functions

On Mon, 9 Jul 2018, Arnd Bergmann wrote:

> 
> The most likely explanation I have here is that the RTC was indeed set 
> to an incorrect date, either because of a depleted battery (not unlikely 
> for a ~15 year old box) or because it was previously stored incorrectly.

The PowerMac stores the GMT offset in NVRAM, and this gets used to 
initialize timezone_offset.

If timezone_offset was negative and now.tv_sec was zero, I think this 
could store a 1969 date in the RTC:

int update_persistent_clock64(struct timespec64 now)
{
        struct rtc_time tm;

        if (!ppc_md.set_rtc_time)
                return -ENODEV;

        rtc_time64_to_tm(now.tv_sec + 1 + timezone_offset, &tm);

        return ppc_md.set_rtc_time(&tm);
}

But maybe now.tv_sec can be shown to be greater than timezone_offset.

Then, what would happen when the timezone in /etc/localtime disagrees with 
the timezone_offset stored in NVRAM (PRAM)?

Besides that, if the battery went flat, what use is a backtrace? Why not 
scrap the WARN_ON()?

--