Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7455692imu; Thu, 31 Jan 2019 10:21:41 -0800 (PST) X-Google-Smtp-Source: ALg8bN4tg704g99wIiHzb3g5a6737bdZrfkZiFLyf+5fIzPAKnIglb8NjmBoQNSkVKuqo6E5kCIj X-Received: by 2002:a65:47ca:: with SMTP id f10mr26397389pgs.166.1548958901131; Thu, 31 Jan 2019 10:21:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548958901; cv=none; d=google.com; s=arc-20160816; b=aHZYzKj3/Xg8BFJlJ8LVw0MmvBAgEwGlXKjioGPUwX+7dDSXEL54RW+xy12HI8Bxjm ir7qmcf4RYBZyGJQZ8CsbfkGYQxqzsZSI4INq/xNGNB8prOt0GVRxVFlktbKvygBO9+N HBidec5YS6HM0gVtCwTMR6QKX/XEiwP9wzIhG7MPrDlF+tYZsUfQJHaaWsY/p6IaaKrl 5vxsXTyF8FV4bQdqakptDPXD5fi4fZbLop5VMeG21l0YmlqHAWT6WqD2fX1UHNLm06bC W3bDq4a1maVLdqVkYPHqBiSwiM82gBYm0YyviulESq0VzZt4X1ISi7TIQNzrG/lT8z+i /2iQ== 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:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=wM1wnMNlONPviRbopyqHO2tp7xeoguel5SrR3EJmojU=; b=zor3St1S5NG/vOp5mvRtq2V5MVA2y+U0sKPigG1qr8zao0ZG7RlY25p1n/FIwEoGv0 r5vprGNglQniBLDz/odhWVdR63yzmzJJM4UtNXvpCsDjSIvc1gn5Lrdjp4zWr1xksMj+ kwyYyt/0D37rezs1Koq1/hcaQXgBL3IJOJRFhURrU58Lo2HjZIVK64ED9/N9+lNDxv42 yIFcBiWuND8erZGm3v3rgeEnQZI+S4PwOZoueXyzX0Y1dcf0NxT8pUKQCGPH4gOhPt8L Eit4F8iG39WdPY7jT/lxopcRCLpPKrl5xPQ9ZCSVhLv+bfv/gGBQR0vSHfmSWpFjaUhk eT+A== 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 v9si4829223pgt.464.2019.01.31.10.21.26; Thu, 31 Jan 2019 10:21:41 -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 S1727723AbfAaRz5 (ORCPT + 99 others); Thu, 31 Jan 2019 12:55:57 -0500 Received: from foss.arm.com ([217.140.101.70]:48896 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726744AbfAaRz5 (ORCPT ); Thu, 31 Jan 2019 12:55:57 -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 7D95FA78; Thu, 31 Jan 2019 09:55:56 -0800 (PST) Received: from donnerap.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 16CE13F59C; Thu, 31 Jan 2019 09:55:53 -0800 (PST) Date: Thu, 31 Jan 2019 17:55:50 +0000 From: Andre Przywara To: Jeremy Linton Cc: linux-arm-kernel@lists.infradead.org, stefan.wahren@i2se.com, mlangsdo@redhat.com, suzuki.poulose@arm.com, marc.zyngier@arm.com, catalin.marinas@arm.com, julien.thierry@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, steven.price@arm.com, ykaukab@suse.de, dave.martin@arm.com, shankerd@codeaurora.org Subject: Re: [PATCH v4 11/12] arm64: add sysfs vulnerability show for speculative store bypass Message-ID: <20190131175550.1e96e80f@donnerap.cambridge.arm.com> In-Reply-To: <20190125180711.1970973-12-jeremy.linton@arm.com> References: <20190125180711.1970973-1-jeremy.linton@arm.com> <20190125180711.1970973-12-jeremy.linton@arm.com> Organization: ARM X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; aarch64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 25 Jan 2019 12:07:10 -0600 Jeremy Linton wrote: Hi, > 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 | 45 ++++++++++++++++++++++++++++++++++ > 1 file changed, 45 insertions(+) > > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c > index caedf268c972..e9ae8e5fd7e1 100644 > --- a/arch/arm64/kernel/cpu_errata.c > +++ b/arch/arm64/kernel/cpu_errata.c > @@ -265,6 +265,7 @@ static int detect_harden_bp_fw(void) > 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; > @@ -362,10 +363,16 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry, > { > struct arm_smccc_res res; > bool required = true; > + bool is_vul; I don't think you need this variable, you can just call is_midr_in_range_list() directly. > 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; > + > if (this_cpu_has_cap(ARM64_SSBS)) { > required = false; > goto out_printmsg; > @@ -399,6 +406,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; > @@ -454,6 +462,16 @@ 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), > + {}, > +}; > + > static void __maybe_unused > cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused) > { > @@ -743,6 +761,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, > }, > #ifdef CONFIG_ARM64_ERRATUM_1188873 > { > @@ -784,4 +803,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) w/s issue Cheers, Andre. > +{ > + /* > + * 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"); > + > + return sprintf(buf, "Vulnerable\n"); > +} > + > #endif