linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>,
	Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-msm@vger.kernel.org,
	Douglas Anderson <dianders@chromium.org>,
	Stephen Boyd <swboyd@chromium.org>,
	linux-arm-kernel@lists.infradead.org,
	Andre Przywara <andre.przywara@arm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: Add KRYO4XX gold CPU core to spectre-v2 safe list
Date: Thu, 13 Aug 2020 11:39:43 +0100	[thread overview]
Message-ID: <ff6fa7bd817d49e8ef9bee5c1e13d99c@kernel.org> (raw)
In-Reply-To: <20200813094041.GA9894@willie-the-truck>

On 2020-08-13 10:40, Will Deacon wrote:
> On Thu, Aug 13, 2020 at 02:49:37PM +0530, Sai Prakash Ranjan wrote:
>> On 2020-08-13 14:33, Will Deacon wrote:
>> > On Thu, Aug 13, 2020 at 01:48:34PM +0530, Sai Prakash Ranjan wrote:
>> > > KRYO4XX gold/big CPU cores are based on Cortex-A76 which has CSV2
>> > > bits set and are spectre-v2 safe. But on big.LITTLE systems where
>> > > they are coupled with other CPU cores such as the KRYO4XX silver
>> > > based on Cortex-A55 which are spectre-v2 safe but do not have CSV2
>> > > bits set, the system wide safe value will be set to the lowest value
>> > > of CSV2 bits as per FTR_LOWER_SAFE defined for CSV2 bits of register
>> > > ID_AA64PFR0_EL1.
>> > >
>> > > This is a problem when booting a guest kernel on gold CPU cores
>> > > where it will incorrectly report ARM_SMCCC_ARCH_WORKAROUND_1 warning
>> > > and consider them as vulnerable for Spectre variant 2 due to system
>> > > wide safe value which is used in kvm emulation code when reading id
>> > > registers. One wrong way of fixing this is to set the FTR_HIGHER_SAFE
>> > > for CSV2 bits, so instead add the KRYO4XX gold CPU core to the safe
>> > > list which will be consulted even when the sanitised read reports
>> > > that CSV2 bits are not set for KRYO4XX gold cores.
>> > >
>> > > Reported-by: Stephen Boyd <swboyd@chromium.org>
>> > > Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> > > ---
>> > >  arch/arm64/kernel/cpu_errata.c | 1 +
>> > >  1 file changed, 1 insertion(+)
>> > >
>> > > diff --git a/arch/arm64/kernel/cpu_errata.c
>> > > b/arch/arm64/kernel/cpu_errata.c
>> > > index 6bd1d3ad037a..6cbdd2d98a2a 100644
>> > > --- a/arch/arm64/kernel/cpu_errata.c
>> > > +++ b/arch/arm64/kernel/cpu_errata.c
>> > > @@ -545,6 +545,7 @@ static const struct midr_range
>> > > spectre_v2_safe_list[] = {
>> > >  	MIDR_ALL_VERSIONS(MIDR_HISI_TSV110),
>> > >  	MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_3XX_SILVER),
>> > >  	MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_SILVER),
>> > > +	MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_GOLD),
>> >
>> > We shouldn't be putting CPUs in the safe list when they have CSV2
>> > reporting
>> > that they are mitigated in hardware, so I don't think this is the right
>> > approach.
>> >
>> 
>> Ok but the only thing I find wrong in this approach is that it is a
>> redundant
>> information because CSV2 is already advertising the mitigation, but 
>> again
>> CSV2 check is done first so it doesn't really hurt to add it to the 
>> safe
>> list because we already know that it is safe.
> 
> It simply doesn't scale. That's why CSV2 exists in the first place, so 
> we
> don't have to modify the kernel everytime a new CPU is invented.
> 
>> > Sounds more like KVM should advertise CSV2 for the vCPUs if all of the
>> > physical CPUs without CSV2 set are on the safe list. But then again, KVM
>> > has always been slightly in denial about big.LITTLE because you can't
>> > sensibly expose it to a guest if there are detectable differences...
>> >
>> 
>> Sorry but I don't see how the guest kernel will see the CSV2 bits set 
>> for
>> gold CPU cores without actually adding them to the safe list or 
>> reading the
>> not sanitised value of ID_AA64PFR0_EL1 ?
> 
> Well that's for somebody to figure out in the patch. I'm just saying 
> that
> adding cores to the safe list when they already have a CSV2 field 
> conveying
> the same information is the wrong approach. The right appproach is for 
> KVM
> to expose CSV2 as set when the system is not affected by the erratum.

A sensible way to fix this would be with something like that:

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 077293b5115f..2735db21ff0d 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1131,6 +1131,9 @@ static u64 read_id_reg(const struct kvm_vcpu 
*vcpu,
  		if (!vcpu_has_sve(vcpu))
  			val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
  		val &= ~(0xfUL << ID_AA64PFR0_AMU_SHIFT);
+		if (!(val & (0xfUL << ID_AA64PFR0_CSV2_SHIFT)) &&
+		    get_spectre_v2_workaround_state() == 
ARM64_BP_HARDEN_NOT_REQUIRED)
+			val |= (1UL << ID_AA64PFR0_CSV2_SHIFT);
  	} else if (id == SYS_ID_AA64ISAR1_EL1 && !vcpu_has_ptrauth(vcpu)) {
  		val &= ~((0xfUL << ID_AA64ISAR1_APA_SHIFT) |
  			 (0xfUL << ID_AA64ISAR1_API_SHIFT) |


         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

  reply	other threads:[~2020-08-13 10:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-13  8:18 [PATCH] arm64: Add KRYO4XX gold CPU core to spectre-v2 safe list Sai Prakash Ranjan
2020-08-13  9:03 ` Will Deacon
2020-08-13  9:19   ` Sai Prakash Ranjan
2020-08-13  9:40     ` Will Deacon
2020-08-13 10:39       ` Marc Zyngier [this message]
2020-08-13 12:33         ` Sai Prakash Ranjan
2020-08-13 17:59           ` Marc Zyngier
2020-08-14  4:34             ` Sai Prakash Ranjan
2020-08-14  8:17               ` Marc Zyngier
2020-08-14  8:32                 ` Sai Prakash Ranjan

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=ff6fa7bd817d49e8ef9bee5c1e13d99c@kernel.org \
    --to=maz@kernel.org \
    --cc=andre.przywara@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dianders@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=saiprakash.ranjan@codeaurora.org \
    --cc=suzuki.poulose@arm.com \
    --cc=swboyd@chromium.org \
    --cc=will@kernel.org \
    /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).