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=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 1A2B8C55178 for ; Wed, 21 Oct 2020 14:40:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6A68A2224E for ; Wed, 21 Oct 2020 14:40:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="DUu8JvTR"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="wPMWulxC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A68A2224E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=fpi3gDy0w1MXeMg9YzPDec7v8FG87h62MgYC/GqRDYo=; b=DUu8JvTR9CrRATQ8Gm2GGcKVn BmQvrt6pHH7e4Xvh0S3SFkw0vR06Vpbd4Ru42P0qSj3bJs9BLxkOIqKPQ5FHEgiVdTi0c+TSTfLyU ny9il1TWbrhbkFGjrcq3FLuPI6rs2d42AUCY45CuF2ARpjTnZQ8iF5ctVHOjMVcrBjyJCyOBmQw7S XS9J3B1AJtbZX9Q1QvG+cIyc/7VASCmhyRo7geITYmUsR29xI3AT2u71gARqyxDwByjpAuu5e1Sbz GVFr87dSwvBzpIjKy2MB+1Lj1ryKNwBtZ57lrSQWdUANQBeOFYrNwJSX5yq5LO8811/bk6FNrNx/J uN/2nNulA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVFGU-0006Jm-11; Wed, 21 Oct 2020 14:38:58 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVFGR-0006Iv-AQ for linux-arm-kernel@lists.infradead.org; Wed, 21 Oct 2020 14:38:56 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (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 346C92224E; Wed, 21 Oct 2020 14:38:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603291134; bh=aZaFr7bcAypuT1NS+VoaGZT3puuco1/g12qVUR/cnKw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=wPMWulxCnblY816bjI0U5d5p2Yql/b4jUnEc+Gwihfhnff+Wj5sNnACto9M+kwg1E gcAwkScATwG6i13LZWLloiyc+8BeAv63+9D8ipiyuAV/3GKNIfODsQIEafpYMqDsmP Y5c3/qKd9tVdwYVsWDKVqCyya6+G4A+oJgocUsHc= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kVFGO-003448-4y; Wed, 21 Oct 2020 15:38:52 +0100 MIME-Version: 1.0 Date: Wed, 21 Oct 2020 15:38:52 +0100 From: Marc Zyngier To: Will Deacon Subject: Re: [PATCH] arm64: spectre-v2: Favour CPU-specific mitigation at EL2 In-Reply-To: <20201021105212.17634-1-will@kernel.org> References: <20201021105212.17634-1-will@kernel.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <7243abdb75c1b51a03dff3f29c82624d@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: will@kernel.org, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201021_103855_516311_4B7CD790 X-CRM114-Status: GOOD ( 30.79 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Will, $subject seems slightly off. Don't we actually want to favor CPU-specific mitigation at *EL1*? On 2020-10-21 11:52, Will Deacon wrote: > Spectre-v2 can be mitigated on Falkor CPUs either by calling into > firmware or by issuing a magic, CPU-specific sequence of branches. > Although the latter is faster, the size of the code sequence means that > it cannot be used in the EL2 vectors, and so there is a need for both > mitigations to co-exist in order to achieve optimal performance. > > Change the mitigation selection logic for Spectre-v2 so that the > CPU-specific mitigation is used only when the firmware mitigation is > also available, rather than when a firmware mitigation is unavailable. > > Cc: Marc Zyngier > Signed-off-by: Will Deacon > --- > arch/arm64/kernel/proton-pack.c | 36 ++++++++++++++++----------------- > 1 file changed, 17 insertions(+), 19 deletions(-) > > diff --git a/arch/arm64/kernel/proton-pack.c > b/arch/arm64/kernel/proton-pack.c > index 68b710f1b43f..5029ef14fb27 100644 > --- a/arch/arm64/kernel/proton-pack.c > +++ b/arch/arm64/kernel/proton-pack.c > @@ -67,7 +67,8 @@ ssize_t cpu_show_spectre_v1(struct device *dev, > struct device_attribute *attr, > * - Mitigated in hardware and advertised by ID_AA64PFR0_EL1.CSV2. > * - Mitigated in hardware and listed in our "safe list". > * - Mitigated in software by firmware. > - * - Mitigated in software by a CPU-specific dance in the kernel. > + * - Mitigated in software by a CPU-specific dance in the kernel and a > + * firmware call at EL2. > * - Vulnerable. > * > * It's not unlikely for different CPUs in a big.LITTLE system to fall > into > @@ -259,6 +260,16 @@ static void qcom_link_stack_sanitisation(void) > : "=&r" (tmp)); > } > > +static bp_hardening_cb_t spectre_v2_get_sw_mitigation_cb(void) > +{ > + u32 midr = read_cpuid_id(); > + if (((midr & MIDR_CPU_MODEL_MASK) != MIDR_QCOM_FALKOR) && > + ((midr & MIDR_CPU_MODEL_MASK) != MIDR_QCOM_FALKOR_V1)) > + return NULL; > + > + return qcom_link_stack_sanitisation; > +} > + > static enum mitigation_state spectre_v2_enable_fw_mitigation(void) > { > bp_hardening_cb_t cb; > @@ -284,26 +295,15 @@ static enum mitigation_state > spectre_v2_enable_fw_mitigation(void) > return SPECTRE_VULNERABLE; > } > > + /* > + * Prefer a CPU-specific workaround if it exists. Note that we > + * still rely on firmware for the mitigation at EL2. > + */ > + cb = spectre_v2_get_sw_mitigation_cb() ?: cb; > install_bp_hardening_cb(cb); > return SPECTRE_MITIGATED; > } > > -static enum mitigation_state spectre_v2_enable_sw_mitigation(void) > -{ > - u32 midr; > - > - if (spectre_v2_mitigations_off()) > - return SPECTRE_VULNERABLE; > - > - midr = read_cpuid_id(); > - if (((midr & MIDR_CPU_MODEL_MASK) != MIDR_QCOM_FALKOR) && > - ((midr & MIDR_CPU_MODEL_MASK) != MIDR_QCOM_FALKOR_V1)) > - return SPECTRE_VULNERABLE; > - > - install_bp_hardening_cb(qcom_link_stack_sanitisation); > - return SPECTRE_MITIGATED; > -} > - > void spectre_v2_enable_mitigation(const struct arm64_cpu_capabilities > *__unused) > { > enum mitigation_state state; > @@ -313,8 +313,6 @@ void spectre_v2_enable_mitigation(const struct > arm64_cpu_capabilities *__unused) > state = spectre_v2_get_cpu_hw_mitigation_state(); > if (state == SPECTRE_VULNERABLE) > state = spectre_v2_enable_fw_mitigation(); > - if (state == SPECTRE_VULNERABLE) > - state = spectre_v2_enable_sw_mitigation(); > > update_mitigation_state(&spectre_v2_state, state); > } This mostly works on QDF2400, except for one odd case: - I boot a host with mitigations disabled - I boot a guest with mitigations enabled The host says "Vulnerable", which is expected. The guest says "Vulnerable", despite being able to mitigate things at EL1 on its own. I'm inclined to say that it should say "Mitigated", but it isn't clear whether that's always safe (the lack of FW mitigation is a hint, but not a certainty). Anyway, not a big deal, as it only affects a system that hardly anyone has access to, for a pretty nonsensical setup. Tested-by: Marc Zyngier Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel