linux-kernel - Re: [PATCH] MIPS: Fix CP0 counter erratum detection for R4k CPUs

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: <CAAdtpL6=b9hYeBggV3XNUtkOMxd=Zt0_7-TkKKdCTku2y1ip+g@mail.gmail.com>
Date:   Fri, 29 Apr 2022 15:04:07 +0200
From:   Philippe Mathieu-Daudé <f4bug@...at.org>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        "open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        stable@...r.kernel.org
Subject: Re: [PATCH] MIPS: Fix CP0 counter erratum detection for R4k CPUs

On Mon, Apr 25, 2022 at 9:39 AM Maciej W. Rozycki <macro@...am.me.uk> wrote:
>
> Fix the discrepancy between the two places we check for the CP0 counter
> erratum in along with the incorrect comparison of the R4400 revision
> number against 0x30 which matches none and consistently consider all
> R4000 and R4400 processors affected, as documented in processor errata
> publications[1][2][3], following the mapping between CP0 PRId register
> values and processor models:
>
>   PRId   |  Processor Model
> ---------+--------------------
> 00000422 | R4000 Revision 2.2
> 00000430 | R4000 Revision 3.0
> 00000440 | R4400 Revision 1.0
> 00000450 | R4400 Revision 2.0
> 00000460 | R4400 Revision 3.0
>
> No other revision of either processor has ever been spotted.
>
> Contrary to what has been stated in commit ce202cbb9e0b ("[MIPS] Assume
> R4000/R4400 newer than 3.0 don't have the mfc0 count bug") marking the
> CP0 counter as buggy does not preclude it from being used as either a
> clock event or a clock source device.  It just cannot be used as both at
> a time, because in that case clock event interrupts will be occasionally
> lost, and the use as a clock event device takes precedence.
>
> Compare against 0x4ff in `can_use_mips_counter' so that a single machine
> instruction is produced.
>
> References:
>
> [1] "MIPS R4000PC/SC Errata, Processor Revision 2.2 and 3.0", MIPS
>     Technologies Inc., May 10, 1994, Erratum 53, p.13
>
> [2] "MIPS R4400PC/SC Errata, Processor Revision 1.0", MIPS Technologies
>     Inc., February 9, 1994, Erratum 21, p.4
>
> [3] "MIPS R4400PC/SC Errata, Processor Revision 2.0 & 3.0", MIPS
>     Technologies Inc., January 24, 1995, Erratum 14, p.3
>
> Signed-off-by: Maciej W. Rozycki <macro@...am.me.uk>
> Fixes: ce202cbb9e0b ("[MIPS] Assume R4000/R4400 newer than 3.0 don't have the mfc0 count bug")
> Cc: stable@...r.kernel.org # v2.6.24+
> ---
>  arch/mips/include/asm/timex.h |    8 ++++----
>  arch/mips/kernel/time.c       |   11 +++--------
>  2 files changed, 7 insertions(+), 12 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <f4bug@...at.org>