linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Linton <jeremy.linton@arm.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
	linux-arm-kernel@lists.infradead.org
Cc: stefan.wahren@i2se.com, mlangsdo@redhat.com,
	suzuki.poulose@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 v3 6/7] arm64: add sysfs vulnerability show for speculative store bypass
Date: Mon, 14 Jan 2019 10:37:26 -0600	[thread overview]
Message-ID: <762faf42-6806-bba9-091c-c21e6955e17d@arm.com> (raw)
In-Reply-To: <ac625845-fd40-ad87-4efd-ea0ed53274ec@arm.com>

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 <jeremy.linton@arm.com>
>> ---
>>   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.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-01-14 16:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09 23:55 [PATCH v3 0/7] arm64: add system vulnerability sysfs entries Jeremy Linton
2019-01-09 23:55 ` [PATCH v3 1/7] sysfs/cpu: Allow individual architectures to select vulnerabilities Jeremy Linton
2019-01-14 10:02   ` Suzuki K Poulose
2019-01-18 15:46     ` Greg KH
2019-01-18 16:31       ` Jeremy Linton
2019-01-09 23:55 ` [PATCH v3 2/7] arm64: add sysfs vulnerability show for spectre v1 Jeremy Linton
2019-01-09 23:55 ` [PATCH v3 3/7] arm64: kpti: move check for non-vulnerable CPUs to a function Jeremy Linton
2019-01-12 10:41   ` Stefan Wahren
2019-01-14 11:32   ` Suzuki K Poulose
2019-01-18 16:35     ` Jeremy Linton
2019-01-09 23:55 ` [PATCH v3 4/7] arm64: add sysfs vulnerability show for meltdown Jeremy Linton
2019-01-10  9:23   ` Julien Thierry
2019-01-10 14:10     ` Jeremy Linton
2019-01-10 14:16       ` Julien Thierry
2019-01-09 23:55 ` [PATCH v3 5/7] arm64: add sysfs vulnerability show for spectre v2 Jeremy Linton
2019-01-09 23:55 ` [PATCH v3 6/7] arm64: add sysfs vulnerability show for speculative store bypass Jeremy Linton
2019-01-14 10:15   ` Marc Zyngier
2019-01-14 16:37     ` Jeremy Linton [this message]
2019-01-14 17:05       ` Marc Zyngier
2019-01-09 23:55 ` [PATCH v3 7/7] arm64: enable generic CPU vulnerabilites support Jeremy Linton
2019-01-15 19:50 ` [PATCH v3 0/7] arm64: add system vulnerability sysfs entries Stefan Wahren
2019-01-15 21:21   ` Jeremy Linton
2019-01-18 18:05     ` Stefan Wahren
2019-01-18 22:22       ` Jeremy Linton
2019-01-19 11:52         ` Stefan Wahren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=762faf42-6806-bba9-091c-c21e6955e17d@arm.com \
    --to=jeremy.linton@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dave.martin@arm.com \
    --cc=julien.thierry@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mlangsdo@redhat.com \
    --cc=shankerd@codeaurora.org \
    --cc=stefan.wahren@i2se.com \
    --cc=steven.price@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will.deacon@arm.com \
    --cc=ykaukab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).