linux-kernel - Re: [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: <41GGZC26Lyz9s1R@ozlabs.org>
Date:   Thu, 28 Jun 2018 07:41:23 +1000 (AEST)
From:   Michael Ellerman <patch-notifications@...erman.id.au>
To:     Arnd Bergmann <arnd@...db.de>, Paul Mackerras <paulus@...ba.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Joshua Thompson <funaho@...ai.org>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Mathieu Malaterre <malat@...ian.org>,
        Meelis Roos <mroos@...ux.ee>, linux-kernel@...r.kernel.org,
        y2038@...ts.linaro.org, linux-m68k@...ts.linux-m68k.org,
        Andreas Schwab <schwab@...ux-m68k.org>,
        linuxppc-dev@...ts.ozlabs.org, Greg Ungerer <gerg@...ux-m68k.org>
Subject: Re: [1/3,v2] powerpc: mac: fix rtc read/write functions

On Tue, 2018-06-19 at 14:02:27 UTC, Arnd Bergmann wrote:
> As Mathieu pointed out, my conversion to time64_t was incorrect and resulted
> in negative times to be read from the RTC. The problem is that during the
> conversion from a byte array to a time64_t, the 'unsigned char' variable
> holding the top byte gets turned into a negative signed 32-bit integer
> before being assigned to the 64-bit variable for any times after 1972.
> 
> This changes the logic to cast to an unsigned 32-bit number first for
> the Macintosh time and then convert that to the Unix time, which then gives
> us a time in the documented 1904..2040 year range. I decided not to use
> the longer 1970..2106 range that other drivers use, for consistency with
> the literal interpretation of the register, but that could be easily
> changed if we decide we want to support any Mac after 2040.
> 
> Just to be on the safe side, I'm also adding a WARN_ON that will trigger
> if either the year 2040 has come and is observed by this driver, or we
> run into an RTC that got set back to a pre-1970 date for some reason
> (the two are indistinguishable).
> 
> For the RTC write functions, Andreas found another problem: both
> pmu_request() and cuda_request() are varargs functions, so changing
> the type of the arguments passed into them from 32 bit to 64 bit
> breaks the API for the set_rtc_time functions. This changes it
> back to 32 bits.
> 
> The same code exists in arch/m68k/ and is patched in an identical way now
> in a separate patch.
> 
> Fixes: 5bfd643583b2 ("powerpc: use time64_t in read_persistent_clock")
> Reported-by: Mathieu Malaterre <malat@...ian.org>
> Reported-by: Andreas Schwab <schwab@...ux-m68k.org>
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> Tested-by: Mathieu Malaterre <malat@...ian.org>

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/22db552b50fa11d8c1d171de908a1f

cheers