Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3765575imu; Mon, 14 Jan 2019 08:39:15 -0800 (PST) X-Google-Smtp-Source: ALg8bN58Lvd6ed+60eYBV4UkPHzR/bmSv+O5spw7mbg0oSaIR2Ex3zSrFKja7H/bnyOeb5Y3qq3q X-Received: by 2002:a62:870e:: with SMTP id i14mr26834000pfe.41.1547483955197; Mon, 14 Jan 2019 08:39:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547483955; cv=none; d=google.com; s=arc-20160816; b=06sdmeBtWHsLHvavV2TeLrVt1t9omQ0NeldAuVx+nS1cV/M1BsYpMWN76Vi2tnrEKv yVHTQvxNdCgbR7Uva39pzi3PYGtsGd4a8ExbhNa7HWa0dDkd4JEuHx4RrPEo8j8zGnI9 /LqbBIk0mHwWCtFxHz/ATyLNhooqYD/8SARCBx6fNsOtVS3u7LpHs3h4KQ34IdihWXHq /3lS/cBr6rTPgBMk9VxzSIuhuiKX2VR+7ADAn0txblYxs4x5gdeqH3BP77Ye/Mbl6mQK 98f0zZadCSz5mWb83JPBF3wEIbgdX2Yi9FZ5fu1zY0ckyKRBuAtM0B5u4vQjlbsdyQA/ a1zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=aTFiS7XyVq9+1+YRUUgTZakujsK+zCyE7fLzG++FUGw=; b=iZ9heVP6APFUMVQvkNevqwaBg24vmPwfIl89TgZ1H3YfzGx64MjXGwjFlJz/DEwWRs Gw0vcd5Dm+10bvFmVJ5joAsricMxHxyjsdBPpHcFSofC3TTFSJsKK8lke3ZAx2nYjn2o YIzFAUs8H3IA0pA6WQw+oTAqbuv5I6Wr9Wx3mnVnp+WMbbuEIkwQjMo3rpU63vTzhAZa lDal01ZZF7UqNqWYggIWCt3YiONe6qJVblLbjYfNwxq17yQPngV/bst+1VHUobuFSXBS lp/NT+z/RpNiLUNdLPEt4EAzp83USX6B9cCQ4vrGvhpZEztF4fGym773wp/nO7ZUmBhK fkaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g21si636245plo.435.2019.01.14.08.38.58; Mon, 14 Jan 2019 08:39:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726876AbfANQh2 (ORCPT + 99 others); Mon, 14 Jan 2019 11:37:28 -0500 Received: from foss.arm.com ([217.140.101.70]:37100 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726674AbfANQh2 (ORCPT ); Mon, 14 Jan 2019 11:37:28 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B3342A78; Mon, 14 Jan 2019 08:37:27 -0800 (PST) Received: from [192.168.100.241] (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F0E543F5BD; Mon, 14 Jan 2019 08:37:26 -0800 (PST) Subject: Re: [PATCH v3 6/7] arm64: add sysfs vulnerability show for speculative store bypass To: Marc Zyngier , linux-arm-kernel@lists.infradead.org Cc: catalin.marinas@arm.com, will.deacon@arm.com, suzuki.poulose@arm.com, dave.martin@arm.com, shankerd@codeaurora.org, linux-kernel@vger.kernel.org, ykaukab@suse.de, julien.thierry@arm.com, mlangsdo@redhat.com, steven.price@arm.com, stefan.wahren@i2se.com References: <20190109235544.2992426-1-jeremy.linton@arm.com> <20190109235544.2992426-7-jeremy.linton@arm.com> From: Jeremy Linton Message-ID: <762faf42-6806-bba9-091c-c21e6955e17d@arm.com> Date: Mon, 14 Jan 2019 10:37:26 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 01/14/2019 04:15 AM, Marc Zyngier wrote: > On 09/01/2019 23:55, Jeremy Linton wrote: >> Return status based on ssbd_state and the arm64 SSBS feature. If >> the mitigation is disabled, or the firmware isn't responding then >> return the expected machine state based on a new blacklist of known >> vulnerable cores. >> >> Signed-off-by: Jeremy Linton >> --- >> arch/arm64/kernel/cpu_errata.c | 48 ++++++++++++++++++++++++++++++++++ >> 1 file changed, 48 insertions(+) >> >> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c >> index ee286d606d9b..c8ff96158b94 100644 >> --- a/arch/arm64/kernel/cpu_errata.c >> +++ b/arch/arm64/kernel/cpu_errata.c >> @@ -288,6 +288,7 @@ enable_smccc_arch_workaround_1(const struct arm64_cpu_capabilities *entry) >> DEFINE_PER_CPU_READ_MOSTLY(u64, arm64_ssbd_callback_required); >> >> int ssbd_state __read_mostly = ARM64_SSBD_KERNEL; >> +static bool __ssb_safe = true; >> >> static const struct ssbd_options { >> const char *str; >> @@ -385,10 +386,18 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry, >> { >> struct arm_smccc_res res; >> bool required = true; >> + bool is_vul; >> s32 val; >> >> WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible()); >> >> + is_vul = is_midr_in_range_list(read_cpuid_id(), entry->midr_range_list); >> + >> + if (is_vul) >> + __ssb_safe = false; >> + >> + arm64_requested_vuln_attrs |= VULN_SSB; >> + >> if (this_cpu_has_cap(ARM64_SSBS)) { >> required = false; >> goto out_printmsg; >> @@ -422,6 +431,7 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry, >> ssbd_state = ARM64_SSBD_UNKNOWN; >> return false; >> >> + /* machines with mixed mitigation requirements must not return this */ >> case SMCCC_RET_NOT_REQUIRED: >> pr_info_once("%s mitigation not required\n", entry->desc); >> ssbd_state = ARM64_SSBD_MITIGATED; >> @@ -476,6 +486,17 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry, >> >> return required; >> } >> + >> +/* known vulnerable cores */ >> +static const struct midr_range arm64_ssb_cpus[] = { >> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A57), >> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A72), >> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A73), >> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A75), >> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A76), >> + {}, >> +}; >> + >> #endif /* CONFIG_ARM64_SSBD */ >> >> static void __maybe_unused >> @@ -762,6 +783,7 @@ const struct arm64_cpu_capabilities arm64_errata[] = { >> .capability = ARM64_SSBD, >> .type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM, >> .matches = has_ssbd_mitigation, >> + .midr_range_list = arm64_ssb_cpus, >> }, >> #endif >> #ifdef CONFIG_ARM64_ERRATUM_1188873 >> @@ -809,4 +831,30 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr, >> return sprintf(buf, "Vulnerable\n"); >> } >> >> +ssize_t cpu_show_spec_store_bypass(struct device *dev, >> + struct device_attribute *attr, char *buf) >> +{ >> + /* >> + * Two assumptions: First, get_ssbd_state() reflects the worse case >> + * for hetrogenous machines, and that if SSBS is supported its >> + * supported by all cores. >> + */ >> + switch (arm64_get_ssbd_state()) { >> + case ARM64_SSBD_MITIGATED: >> + return sprintf(buf, "Not affected\n"); >> + >> + case ARM64_SSBD_KERNEL: >> + case ARM64_SSBD_FORCE_ENABLE: >> + if (cpus_have_cap(ARM64_SSBS)) >> + return sprintf(buf, "Not affected\n"); >> + return sprintf(buf, >> + "Mitigation: Speculative Store Bypass disabled\n"); >> + } >> + >> + if (__ssb_safe) >> + return sprintf(buf, "Not affected\n"); > > The kbuild robot reports that this fails if CONFIG_ARM64_SSBD is not > selected. What should we print in this case? "Vulnerable"? Or "Unknown"? The immediate fix is that the __ssb_safe variable should be in its own conditional block which is CONFIG_GENERIC_CPU_VULNERABILITIES || CONFIG_ARM64_SSBD. If the mitigation isn't built in then this code won't be run anyway because the sysfs entry won't be populated. But, these CONFIG_ conditionals are less than ideal (and would be even uglier if they were made more efficient). My own opinion at this point is that we should really remove the compile time configs and leave the mitigation built all the time. The raw code is fairly small, and we could add in the nospectre_v2 command line options so that users can choose to runtime disable them. That would also remove the need to modify the core cpu vulnerabilities sysfs code.