linux-kernel - Re: [PATCH 14/18] arm64: erratum: Work around Falkor erratum #E1003 in trampoline code

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: <20171120180548.GL32488@arm.com>
Date:   Mon, 20 Nov 2017 18:05:49 +0000
From:   Will Deacon <will.deacon@....com>
To:     Stephen Boyd <sboyd@...eaurora.org>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        catalin.marinas@....com, mark.rutland@....com,
        ard.biesheuvel@...aro.org, dave.hansen@...ux.intel.com,
        keescook@...omium.org
Subject: Re: [PATCH 14/18] arm64: erratum: Work around Falkor erratum #E1003
 in trampoline code

On Fri, Nov 17, 2017 at 04:27:14PM -0800, Stephen Boyd wrote:
> On 11/17, Will Deacon wrote:
> > We rely on an atomic swizzling of TTBR1 when transitioning from the entry
> > trampoline to the kernel proper on an exception. We can't rely on this
> > atomicity in the face of Falkor erratum #E1003, so on affected cores we
> > can issue a TLB invalidation prior to jumping into the kernel. There is
> > still the possibility of a TLB conflict here due to conflicting walk
> > cache entries, but this doesn't appear to be the case on these CPUs in
> > practice.
> > 
> > Signed-off-by: Will Deacon <will.deacon@....com>
> > ---
> >  arch/arm64/Kconfig        | 17 +++++------------
> >  arch/arm64/kernel/entry.S |  8 ++++++++
> >  2 files changed, 13 insertions(+), 12 deletions(-)
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 0df64a6a56d4..f0fcbfc2262e 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -504,20 +504,13 @@ config CAVIUM_ERRATUM_30115
> >  config QCOM_FALKOR_ERRATUM_1003
> >  	bool "Falkor E1003: Incorrect translation due to ASID change"
> >  	default y
> > -	select ARM64_PAN if ARM64_SW_TTBR0_PAN
> 
> Cool, this sort of complicates the backport of the Kryo MIDR
> update of this errata to stable trees though.

Yeah, you may have to do a separate version for -stable if you don't
want to backport parts of this series.

> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index a839b94bba05..a600879939ce 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -941,6 +941,14 @@ __ni_sys_trace:
> >  	sub	\tmp, \tmp, #(SWAPPER_DIR_SIZE + RESERVED_TTBR0_SIZE)
> >  	bic	\tmp, \tmp, #USER_ASID_FLAG
> >  	msr	ttbr1_el1, \tmp
> > +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
> 
> Shouldn't we put this inside an #ifdef QCOM_FALKOR_ERRATUM_1003
> so that we don't even emit nops in case we have the errata
> disabled? Or did I miss something in the alternatives assembly
> code?

Yes, you're right. Thanks!

Will