On Fri, Oct 25, 2019 at 05:39:44PM +0200, Ard Biesheuvel wrote:
> On Fri, 25 Oct 2019 at 17:28, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
> >
> > On Fri, 25 Oct 2019 at 17:25, Sasha Levin <sashal@xxxxxxxxxx> wrote:
> > >
> > > On Thu, Oct 24, 2019 at 04:37:12PM +0200, Ard Biesheuvel wrote:
> > > >On Thu, 24 Oct 2019 at 16:34, Alexandru Elisei <alexandru.elisei@xxxxxxx> wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> On 10/24/19 1:48 PM, Ard Biesheuvel wrote:
> > > >> > From: Jeremy Linton <jeremy.linton@xxxxxxx>
> > > >> >
> > > >> > [ Upstream commit 8c1e3d2bb44cbb998cb28ff9a18f105fee7f1eb3 ]
> > > >> >
> > > >> > Ensure we are always able to detect whether or not the CPU is affected
> > > >> > by Spectre-v2, so that we can later advertise this to userspace.
> > > >> >
> > > >> > Signed-off-by: Jeremy Linton <jeremy.linton@xxxxxxx>
> > > >> > Reviewed-by: Andre Przywara <andre.przywara@xxxxxxx>
> > > >> > Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx>
> > > >> > Tested-by: Stefan Wahren <stefan.wahren@xxxxxxxx>
> > > >> > Signed-off-by: Will Deacon <will.deacon@xxxxxxx>
> > > >> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
> > > >> > ---
> > > >> > arch/arm64/kernel/cpu_errata.c | 15 ++++++++-------
> > > >> > 1 file changed, 8 insertions(+), 7 deletions(-)
> > > >> >
> > > >> > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> > > >> > index bf6d8aa9b45a..647c533cfd90 100644
> > > >> > --- a/arch/arm64/kernel/cpu_errata.c
> > > >> > +++ b/arch/arm64/kernel/cpu_errata.c
> > > >> > @@ -76,7 +76,6 @@ cpu_enable_trap_ctr_access(const struct arm64_cpu_capabilities *__unused)
> > > >> > config_sctlr_el1(SCTLR_EL1_UCT, 0);
> > > >> > }
> > > >> >
> > > >> > -#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> > > >> > #include <asm/mmu_context.h>
> > > >> > #include <asm/cacheflush.h>
> > > >> >
> > > >> > @@ -217,11 +216,11 @@ static int detect_harden_bp_fw(void)
> > > >> > ((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR_V1))
> > > >> > cb = qcom_link_stack_sanitization;
> > > >> >
> > > >> > - install_bp_hardening_cb(cb, smccc_start, smccc_end);
> > > >> > + if (IS_ENABLED(CONFIG_HARDEN_BRANCH_PREDICTOR))
> > > >> > + install_bp_hardening_cb(cb, smccc_start, smccc_end);
> > > >> >
> > > >> > return 1;
> > > >> > }
> > > >> > -#endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
> > > >> >
> > > >> > DEFINE_PER_CPU_READ_MOSTLY(u64, arm64_ssbd_callback_required);
> > > >> >
> > > >> > @@ -457,7 +456,6 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
> > > >> > .type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM, \
> > > >> > CAP_MIDR_RANGE_LIST(midr_list)
> > > >> >
> > > >> > -#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> > > >> > /*
> > > >> > * List of CPUs that do not need any Spectre-v2 mitigation at all.
> > > >> > */
> > > >> > @@ -489,6 +487,12 @@ check_branch_predictor(const struct arm64_cpu_capabilities *entry, int scope)
> > > >> > if (!need_wa)
> > > >> > return false;
> > > >> >
> > > >> > + if (!IS_ENABLED(CONFIG_HARDEN_BRANCH_PREDICTOR)) {
> > > >> > + pr_warn_once("spectrev2 mitigation disabled by kernel configuration\n");
> > > >> > + __hardenbp_enab = false;
> > > >>
> > > >> This breaks when building, because __hardenbp_enab is declared in the next patch:
> > > >>
> > > >> $ make -j32 defconfig && make -j32
> > > >>
> > > >> [..]
> > > >> arch/arm64/kernel/cpu_errata.c: In function ‘check_branch_predictor’:
> > > >> arch/arm64/kernel/cpu_errata.c:492:3: error: ‘__hardenbp_enab’ undeclared (first
> > > >> use in this function)
> > > >> __hardenbp_enab = false;
> > > >> ^~~~~~~~~~~~~~~
> > > >> arch/arm64/kernel/cpu_errata.c:492:3: note: each undeclared identifier is reported
> > > >> only once for each function it appears in
> > > >> make[1]: *** [scripts/Makefile.build:326: arch/arm64/kernel/cpu_errata.o] Error 1
> > > >> make[1]: *** Waiting for unfinished jobs....
> > > >>
> > > >
> > > >Indeed, but as discussed, this matches the state of both mainline and
> > > >v4.19, which carry these patches in the same [wrong] order as well.
> > > >
> > > >Greg should confirm, but as I understand it, it is preferred to be
> > > >bug-compatible with mainline rather than fixing problems when spotting
> > > >them while doing the backport.
> > >
> > > Is it just patch ordering? If so I'd rather fix it, there's no reason to
> > > carry this issue into the stable trees.
> > >
> > > We reserve "bug compatibility" for functional issues that are not yet
> > > fixed upstream, it doesn't seem to be the case here.
> > >
> >
> > The patches don't apply cleanly in the opposite order.
>
> What we could do is squash the two patches together. That way, we
> avoid the breakage without having to modify the patches in order to be
> able to apply them.
No, don't do that. Just take all of the needed commits.
