linux-kernel - RE: [PATCH V3 2/2] timer: imx-tpm: add imx tpm timer support

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:   Tue, 4 Jul 2017 16:43:29 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "A.s. Dong" <aisheng.dong@....com>
cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        Jacky Bai <ping.bai@....com>,
        Anson Huang <anson.huang@....com>,
        "dongas86@...il.com" <dongas86@...il.com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        Arnd Bergmann <arnd@...db.de>,
        Anson Huang <anson.huang@....com>
Subject: RE: [PATCH V3 2/2] timer: imx-tpm: add imx tpm timer support

On Tue, 4 Jul 2017, A.s. Dong wrote:
> > From: Thomas Gleixner [mailto:tglx@...utronix.de]
> > I'm really impressed, that 10 years after we discovered the HPET disaster
> > (See comment in arch/x86/kernel/hpet.c::hpet_next_event) the same
> > hardware idiocy comes around again....
> > 
> 
> Not quite sure but seems a bit different issue.
> The issue is still uncertain but the test shows it's related to fabric priority
> Configuration, if increase the A7 core priority higher than GPU, the issue
> is very hard to be seen. But we don't want to change the default priority,
> we use ETIME check to fix it.

Well, whether it's hard to be observed or not is not the question. The
point is, that with match equal registers you always have:

      now = read_counter();
      match = now + delta;
      write_match(match);

If the counter advanced past match before the write hits the match
register, then the next interrupt will come after the wrap around of the
counter, which might be close to eternity depending on the counter
frequency and bit width.

This advancement can be caused by a gazillion of reasons:

     - Fabric delays
     - TLB/cache misses
     - .....

The probability might be low, but this can and will happen. And there is
nothing you can do about it. No FIXME in the world will change that
behaviour except that the FIXME actually changes the hardware.

Match equal registers are simply crap in such a context and should never be
used for timers. That's not a new finding, that's well known since 40+
years. But sure, hardware folks are always smarter.

Thanks,

	tglx