linux-kernel - Re: [PATCH] [stable 4.9] arm64: Add work around for Arm Cortex-A55 Erratum 1024718

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] [day] [month] [year] [list]

Date:   Sat, 12 May 2018 16:15:22 +0200
From:   Greg KH <greg@...ah.com>
To:     Suzuki K Poulose <Suzuki.Poulose@....com>
Cc:     stable@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, catalin.marinas@....com,
        will.deacon@....com, mark.rutland@....com
Subject: Re: [PATCH] [stable 4.9] arm64: Add work around for Arm Cortex-A55
 Erratum 1024718

On Fri, May 11, 2018 at 05:06:20PM +0100, Suzuki K Poulose wrote:
> On 11/05/18 16:47, Greg KH wrote:
> > On Fri, May 11, 2018 at 02:51:15PM +0100, Suzuki K Poulose wrote:
> > > commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream
> > > 
> > > Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
> > > from an erratum 1024718, which causes incorrect updates when DBM/AP
> > > bits in a page table entry is modified without a break-before-make
> > > sequence. The work around is to disable the hardware DBM feature
> > > on the affected cores. The hardware Access Flag management features
> > > is not affected.
> > > 
> > > The hardware DBM feature is a non-conflicting capability, i.e, the
> > > kernel could handle cores using the feature and those without having
> > > the features running at the same time. So this work around is detected
> > > at early boot time, rather than delaying it until the CPUs are brought
> > > up into the kernel with MMU turned on. This also avoids other complexities
> > > with late CPUs turning online, with or without the hardware DBM features.
> > > 
> > > Cc: stable@...r.kernel.org # v4.9
> > > Cc: Catalin Marinas <catalin.marinas@....com>
> > > Cc: Mark Rutland <mark.rutland@....com>
> > > Cc: Will Deacon <will.deacon@....com>
> > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
> > > ---
> > > Note: The upstream commit is on top of a reworked capability
> > > infrastructure for arm64 heterogeneous systems, which allows
> > > delaying the CPU model checks. This backport is based on the
> > > original version of the patch [0], which checks the affected
> > > CPU models during the early boot.
> > > 
> > > [0] https://lkml.kernel.org/r/20180116102323.3470-1-suzuki.poulose@arm.com
> > 
> > Now applied, thanks.
> 
> Greg,
> 
> I have the backport for v4.4 ready. But it needs to cherry-pick a commit
> (commit 30b5ba5cf33 : arm64: introduce mov_q macro to move a constant into a 64-bit register)
> which adds the assembly helper and that seems to result in a conflict with
> an obvious resolution. What do you prefer in this case ?
> 
> 1) Go ahead with the cherry-pick

Have 2 patches, the first be the cherry pick and the second be your
backported other patch.  I almost always want the original patches that
are in Linus's tree, otherwise we always get the
merging/squashing/rewrite wrong.

thanks,

greg k-h