Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp258622imb; Thu, 28 Feb 2019 23:13:34 -0800 (PST) X-Google-Smtp-Source: APXvYqwSGr94BEr/Sls87YQYtYqJxI5NUF6wm0ywn7nG0gN5UrdTSKGmFM0PzQj2cvUEQT5TsUxR X-Received: by 2002:a63:545:: with SMTP id 66mr3459343pgf.102.1551424413963; Thu, 28 Feb 2019 23:13:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551424413; cv=none; d=google.com; s=arc-20160816; b=GHwwIlrz+KG5MHo2rK5LaN0Je0CkyEHYpvJ/jT0RcKaGXdmfgx7xS5ikaeE3+ZDPZi y/orQbJ8YMJ3MiUwpF1/PyGwW6GeMpFZoQSc7v7oehno43ARYEG4WJmR96vI4yv+55FX Q4A9S9MxWAy4BODhyVd/XNl6iLyVuMAxbVMyFwtLuxTLBEcJzF9QZGT6FxOyCkvKIZJE ngg+cPvWfWP70T9iYEERn8kQPfW5qJgUPCCtuEwsnRvmsJVYlX7ivbAcxWj90TnfBv+5 KxdOOEspLbO514kPr5cOjtCf2YhPUSonX44NCmuePvjSnkh0NyzK48tn342M/CM2Rpgq wNiQ== 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=Vs5zLEhDwxy9XJuIbsWZ1XgzKRQqIweuRlm6Eos7QX4=; b=Eo04Nb69/DyPVDM79QLWn1o2yrweSbvMhPne5eJ/LcaLsVsuq98AS4IGOBRFtPdOWL b6xhasMR5VuvPD+tkV+wceo++SE7vphuSjUEwKHrHyXwk4YP0JdhWlxSe6MVtOLns0iI 2kMji5QXwSjTJnxwEXul4rINsfv02DMfKrZUT/4OuNR9FUe1+ZGfpl0/AZ2lWtHqPs13 a+uJh5/Za874xOS9V4M6GmdVjbqPKZ8vutG1GoFqTh8ogBEbBKCS7ElISUlhwhlUz7W9 GfFuYpCxIkLK1ZAPKQWIhA0H1AToWvA75vH1G9dbW4FCHUdmWB/UeNqh47oAZOdmQo/f J0aw== 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 f1si17645218plb.396.2019.02.28.23.13.18; Thu, 28 Feb 2019 23:13:33 -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 S1732304AbfCAHLK (ORCPT + 99 others); Fri, 1 Mar 2019 02:11:10 -0500 Received: from foss.arm.com ([217.140.101.70]:58900 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726036AbfCAHLI (ORCPT ); Fri, 1 Mar 2019 02:11:08 -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 4221EEBD; Thu, 28 Feb 2019 23:11:08 -0800 (PST) Received: from [172.20.0.134] (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5DC083F575; Thu, 28 Feb 2019 23:11:07 -0800 (PST) Subject: Re: [PATCH v5 03/10] arm64: add sysfs vulnerability show for meltdown To: Jeremy Linton , linux-arm-kernel@lists.infradead.org Cc: catalin.marinas@arm.com, will.deacon@arm.com, marc.zyngier@arm.com, suzuki.poulose@arm.com, Dave.Martin@arm.com, shankerd@codeaurora.org, julien.thierry@arm.com, mlangsdo@redhat.com, stefan.wahren@i2e.com, linux-kernel@vger.kernel.org References: <20190227010544.597579-1-jeremy.linton@arm.com> <20190227010544.597579-4-jeremy.linton@arm.com> From: Andre Przywara Message-ID: Date: Fri, 1 Mar 2019 01:11:05 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190227010544.597579-4-jeremy.linton@arm.com> 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 2/26/19 7:05 PM, Jeremy Linton wrote: > Display the mitigation status if active, otherwise > assume the cpu is safe unless it doesn't have CSV3 > and isn't in our whitelist. > > Signed-off-by: Jeremy Linton > --- > arch/arm64/kernel/cpufeature.c | 47 ++++++++++++++++++++++++++-------- > 1 file changed, 37 insertions(+), 10 deletions(-) > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index f6d84e2c92fe..d31bd770acba 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -944,7 +944,7 @@ has_useable_cnp(const struct arm64_cpu_capabilities *entry, int scope) > return has_cpuid_feature(entry, scope); > } > > -#ifdef CONFIG_UNMAP_KERNEL_AT_EL0 > +static bool __meltdown_safe = true; > static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */ > > static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry, > @@ -963,6 +963,16 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry, > { /* sentinel */ } > }; > char const *str = "command line option"; > + bool meltdown_safe; > + > + meltdown_safe = is_midr_in_range_list(read_cpuid_id(), kpti_safe_list); > + > + /* Defer to CPU feature registers */ > + if (has_cpuid_feature(entry, scope)) > + meltdown_safe = true; > + > + if (!meltdown_safe) > + __meltdown_safe = false; > > /* > * For reasons that aren't entirely clear, enabling KPTI on Cavium > @@ -974,6 +984,11 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry, > __kpti_forced = -1; > } > > + if (!IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0)) { > + pr_info_once("kernel page table isolation disabled by CONFIG\n"); > + return false; > + } > + > /* Forced? */ > if (__kpti_forced) { > pr_info_once("kernel page table isolation forced %s by %s\n", > @@ -985,14 +1000,10 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry, > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) > return kaslr_offset() > 0; > > - /* Don't force KPTI for CPUs that are not vulnerable */ > - if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list)) > - return false; > - > - /* Defer to CPU feature registers */ > - return !has_cpuid_feature(entry, scope); > + return !meltdown_safe; > } > > +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0 > static void > kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused) > { > @@ -1022,6 +1033,13 @@ kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused) > > return; > } > +#else > +static void > +kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused) > +{ > +} > +#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */ > + > > static int __init parse_kpti(char *str) > { > @@ -1035,7 +1053,6 @@ static int __init parse_kpti(char *str) > return 0; > } > early_param("kpti", parse_kpti); > -#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */ > > #ifdef CONFIG_ARM64_HW_AFDBM > static inline void __cpu_enable_hw_dbm(void) > @@ -1286,7 +1303,6 @@ static const struct arm64_cpu_capabilities arm64_features[] = { > .field_pos = ID_AA64PFR0_EL0_SHIFT, > .min_field_value = ID_AA64PFR0_EL0_32BIT_64BIT, > }, > -#ifdef CONFIG_UNMAP_KERNEL_AT_EL0 > { > .desc = "Kernel page table isolation (KPTI)", > .capability = ARM64_UNMAP_KERNEL_AT_EL0, > @@ -1302,7 +1318,6 @@ static const struct arm64_cpu_capabilities arm64_features[] = { > .matches = unmap_kernel_at_el0, > .cpu_enable = kpti_install_ng_mappings, > }, > -#endif > { > /* FP/SIMD is not implemented */ > .capability = ARM64_HAS_NO_FPSIMD, > @@ -2063,3 +2078,15 @@ static int __init enable_mrs_emulation(void) > } > > core_initcall(enable_mrs_emulation); > + > +ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, > + char *buf) > +{ > + if (arm64_kernel_unmapped_at_el0()) > + return sprintf(buf, "Mitigation: KPTI\n"); > + > + if (__meltdown_safe) > + return sprintf(buf, "Not affected\n"); Shall those two checks be swapped? So it doesn't report about a KPTI mitigation if the CPU is safe, but we enable KPTI because of KASLR having enabled it? Or is that a different knob? Cheers, Andre. > + > + return sprintf(buf, "Vulnerable\n"); > +} >