linux-kernel - Re: [PATCH AUTOSEL for 4.9 173/293] MIPS: Handle tlbex-tlbp race condition

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:   Mon, 9 Apr 2018 21:42:29 +0100
From:   James Hogan <jhogan@...nel.org>
To:     Sasha Levin <Alexander.Levin@...rosoft.com>
Cc:     "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Paul Burton <paul.burton@...tec.com>,
        "linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
        Ralf Baechle <ralf@...ux-mips.org>
Subject: Re: [PATCH AUTOSEL for 4.9 173/293] MIPS: Handle tlbex-tlbp race
 condition

On Mon, Apr 09, 2018 at 12:25:09AM +0000, Sasha Levin wrote:
> From: Paul Burton <paul.burton@...tec.com>
> 
> [ Upstream commit f39878cc5b09c75d35eaf52131e920b872e3feb4 ]
> 
> In systems where there are multiple actors updating the TLB, the
> potential exists for a race condition wherein a CPU hits a TLB exception
> but by the time it reaches a TLBP instruction the affected TLB entry may
> have been replaced. This can happen if, for example, a CPU shares the
> TLB between hardware threads (VPs) within a core and one of them
> replaces the entry that another has just taken a TLB exception for.
> 
> We handle this race in the case of the Hardware Table Walker (HTW) being
> the other actor already, but didn't take into account the potential for
> multiple threads racing. Include the code for aborting TLB exception
> handling in affected multi-threaded systems, those being the I6400 &
> I6500 CPUs which share TLB entries between VPs.
> 
> In the case of using RiXi without dedicated exceptions we have never
> handled this race even for HTW. This patch adds WARN()s to these cases
> which ought never to be hit because all CPUs with either HTW or shared
> FTLB RAMs also include dedicated RiXi exceptions, but the WARN()s will
> ensure this is always the case.

...

> +	/*
> +	 * If the CPU shares FTLB RAM with its siblings then our entry may be
> +	 * replaced at any time by a sibling performing a write to the FTLB.
> +	 */
> +	if (cpu_has_shared_ftlb_ram)

cpu_has_shared_ftlb_ram was only added in v4.13, commit e7bc8557428f
("MIPS: Add CPU shared FTLB feature detection"). To backport this patch
you'd need that one too at least (and I6500 support was also new in 4.13
so you'd also have to drop that case from the backport of that patch).

There may be other dependencies too, I don't know OTOH.

Cheers
James

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)