linux-kernel - Re: [linux-sunxi] Re: [PATCH 0/2] Allwinner A64 timer workaround

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:   Wed, 4 Jul 2018 17:14:50 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andre Przywara <andre.przywara@....com>
cc:     Marc Zyngier <marc.zyngier@....com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Samuel Holland <samuel@...lland.org>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-sunxi@...glegroups.com, Mark Rutland <Mark.Rutland@....com>
Subject: Re: [linux-sunxi] Re: [PATCH 0/2] Allwinner A64 timer workaround

On Wed, 4 Jul 2018, Andre Przywara wrote:
> On 04/07/18 15:31, Thomas Gleixner wrote:
> > If that's the case then you need to find a different functional timer for
> > time keeping. Having an erratic behaving timer for time keeping is not an
> > option at all.
> 
> That's not an option on arm64. There are other usable time sources in
> the SoC, but the arch timer is somewhat mandatory for all practical
> purposes on arm64. We rely on it in some many places that it's not
> feasible to run without it. That's why we call it "architected" timer
> after all ;-)

The argument that it has to be used just because someone defined it as
'architected' is bullshit and doesn't change the fact that it's broken and
not usable for timekeeping. There is no wiggle room. Either it works or
not, but works mostly is not an option.

> But I am quite confident that we can find a correct workaround. Maybe
> it's really the TVAL (the downcounter) write which is the culprit here,
> since the hardware actually writes "now() + TVAL" into the CVAL
> (upcounter) register. This internal counter access may be flawed as well.

If the write to the event device is wreckaging the counter which provides
time, then there is something seriously wrong either in the design or in
that particular piece of silicon.

Yet another proof for the theory that timers are implemented by janitors
and that silicon/IP vendors have a competition running who can create the
most subtly broken timers. Intel surely had a head start with that, but ARM
is definitely catching up.

Thanks,

	tglx