From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1B40CA9EA0 for ; Fri, 25 Oct 2019 15:25:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C5AD021D7B for ; Fri, 25 Oct 2019 15:25:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572017137; bh=dSx7rE1J+3SZP7KDCK328smpGaLJtvBgkr6tq3Ic3co=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=CK0qGTRyudSZGXPdxVDlmLqjY35LJGA5MCp33G0PAfBwXeXoJD0ZN2cR/KHPeig50 qGdzf6+Fy4QDh5/lcPLWRnwBDAY6eOL+pIJyXSDE6wGpTzc51U5l5vTZpTcxOLXyjM 6zXwX2m5nK9kDBxI9T7VXgS4QIGMBmxzOFYbsxco= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2440630AbfJYPZh (ORCPT ); Fri, 25 Oct 2019 11:25:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:53604 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731226AbfJYPZh (ORCPT ); Fri, 25 Oct 2019 11:25:37 -0400 Received: from localhost (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7324721D7F; Fri, 25 Oct 2019 15:25:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572017135; bh=dSx7rE1J+3SZP7KDCK328smpGaLJtvBgkr6tq3Ic3co=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Xz+zgHOH05B2vW4JbReW8JOD6Lt23nD/yJ+ZYTD+KjU40NB0+pMemPkD4eLfnvTtD 7WJhOvrQN1cak2a5Sz48zcY0iDh4F8yKh9OuIDw6sEhP+kEpow6gMycIZjgb9yfjkE 6rEDbqFfW5WwgWCgWFG5Zjw9eK71kUWWZKif1Sqs= Date: Fri, 25 Oct 2019 11:25:34 -0400 From: Sasha Levin To: Ard Biesheuvel Cc: Alexandru Elisei , stable , Will Deacon , Catalin Marinas , Marc Zyngier , Mark Rutland , Suzuki K Poulose , Jeremy Linton , Andre Przywara , Stefan Wahren , Will Deacon Subject: Re: [PATCH for-stable-4.14 42/48] arm64: Always enable spectre-v2 vulnerability detection Message-ID: <20191025152534.GF31224@sasha-vm> References: <20191024124833.4158-1-ard.biesheuvel@linaro.org> <20191024124833.4158-43-ard.biesheuvel@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, Oct 24, 2019 at 04:37:12PM +0200, Ard Biesheuvel wrote: >On Thu, 24 Oct 2019 at 16:34, Alexandru Elisei wrote: >> >> Hi, >> >> On 10/24/19 1:48 PM, Ard Biesheuvel wrote: >> > From: Jeremy Linton >> > >> > [ 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 >> > Reviewed-by: Andre Przywara >> > Reviewed-by: Catalin Marinas >> > Tested-by: Stefan Wahren >> > Signed-off-by: Will Deacon >> > Signed-off-by: Ard Biesheuvel >> > --- >> > 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 >> > #include >> > >> > @@ -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. -- Thanks, Sasha