From: Will Deacon <will.deacon@arm.com>
To: Jayachandran C <jnair@caviumnetworks.com>
Cc: marc.zyngier@arm.com, linux-arm-kernel@lists.infradead.org,
lorenzo.pieralisi@arm.com, ard.biesheuvel@linaro.org,
catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
labbott@redhat.com, christoffer.dall@linaro.org
Subject: Re: [PATCH 2/2] arm64: Branch predictor hardening for Cavium ThunderX2
Date: Mon, 8 Jan 2018 17:23:41 +0000 [thread overview]
Message-ID: <20180108172341.GV25869@arm.com> (raw)
In-Reply-To: <20180108171943.GA180149@jc-sabre>
On Mon, Jan 08, 2018 at 09:19:43AM -0800, Jayachandran C wrote:
> On Mon, Jan 08, 2018 at 04:46:52PM +0000, Will Deacon wrote:
> > On Sun, Jan 07, 2018 at 10:53:36PM -0800, Jayachandran C wrote:
> > > Use PSCI based mitigation for speculative execution attacks targeting
> > > the branch predictor. The approach is similar to the one used for
> > > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to
> > > test if the firmware supports the capability.
> > >
> > > If the secure firmware has been updated with the mitigation code to
> > > invalidate the branch target buffer, we use the PSCI version call to
> > > invoke it.
> > >
> > > Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
> > > ---
> > > arch/arm64/kernel/cpu_errata.c | 38 ++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 38 insertions(+)
> > >
> > > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> > > index cb0fb37..abceb5d 100644
> > > --- a/arch/arm64/kernel/cpu_errata.c
> > > +++ b/arch/arm64/kernel/cpu_errata.c
> > > @@ -124,6 +124,7 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry,
> > > __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end);
> > > }
> > >
> > > +#include <linux/arm-smccc.h>
> > > #include <linux/psci.h>
> > >
> > > static int enable_psci_bp_hardening(void *data)
> > > @@ -138,6 +139,33 @@ static int enable_psci_bp_hardening(void *data)
> > >
> > > return 0;
> > > }
> > > +
> > > +#define CAVIUM_TX2_SIP_SMC_CALL 0xC200FF00
> > > +#define CAVIUM_TX2_BTB_HARDEN_CAP 0xB0A0
> > > +
> > > +static int enable_tx2_psci_bp_hardening(void *data)
> > > +{
> > > + const struct arm64_cpu_capabilities *entry = data;
> > > + struct arm_smccc_res res;
> > > +
> > > + if (!entry->matches(entry, SCOPE_LOCAL_CPU))
> > > + return;
> > > +
> > > + arm_smccc_smc(CAVIUM_TX2_SIP_SMC_CALL, CAVIUM_TX2_BTB_HARDEN_CAP, 0, 0, 0, 0, 0, 0, &res);
> >
> > One thing to be aware of here is that if somebody configures qemu to emulate
> > a TX2, this may actually disappear into EL3 and not return. You're better
> > off sticking with PSCI GET_VERSION in terms of portability, but it's your
> > call -- I'd expect you to deal with any breakage reports on the list due
> > to the SMC above. Fair?
>
> I don't like having a custom SMC here either. But Overloading PSCI get version
> is the problem as I wrote earlier - there is no way to check if the firmware
> implements BTB hardening with overloading. There is a good chance that users
> with old firmware will just fail without any warning.
That's true, but there is precedent for this elsewhere. For example, CPU
errata that require a firmware change are often not probable. Also, your SMC
call won't always work (see the qemu comment below). Note that I'm not
saying I won't take this code, just that you need to be aware of what
you're doing.
> Is there a reason for overloading PSCI get version? Allocating a new standard
> SMC number would make checking for existance and usage much simpler.
PSCI get version is what we have today. We're working on extending PSCI to
allocate a new standard SMC number, but we need something that can be used
with existing firmware too and standardisation doesn't happen overnight.
> I did not quite understand the possible issue in qemu, unimplemented SMC calls
> are expected to return an error code. What am I missing here?
Qemu will inject them into EL3, and there might not be anything there.
Will
next prev parent reply other threads:[~2018-01-08 17:23 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-05 13:12 [PATCH v2 00/11] arm64 kpti hardening and variant 2 workarounds Will Deacon
2018-01-05 13:12 ` [PATCH v2 01/11] arm64: use RET instruction for exiting the trampoline Will Deacon
2018-01-06 13:13 ` Ard Biesheuvel
2018-01-08 14:33 ` Will Deacon
2018-01-08 14:38 ` Ard Biesheuvel
2018-01-08 14:45 ` Will Deacon
2018-01-08 14:56 ` Ard Biesheuvel
2018-01-08 15:27 ` David Laight
2018-01-05 13:12 ` [PATCH v2 02/11] arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry Will Deacon
2018-01-05 13:12 ` [PATCH v2 03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3 Will Deacon
2018-01-08 7:24 ` [v2,03/11] " Jayachandran C
2018-01-08 9:20 ` Marc Zyngier
2018-01-08 17:40 ` Jayachandran C
2018-01-08 17:51 ` Will Deacon
2018-01-08 18:22 ` Alan Cox
2018-01-09 4:06 ` Jayachandran C
2018-01-09 10:00 ` Will Deacon
2018-01-19 1:00 ` Jon Masters
2018-01-08 17:52 ` Marc Zyngier
2018-01-08 17:06 ` Will Deacon
2018-01-08 17:50 ` Jayachandran C
2018-01-05 13:12 ` [PATCH v2 04/11] arm64: cpufeature: Pass capability structure to ->enable callback Will Deacon
2018-01-05 13:12 ` [PATCH v2 05/11] drivers/firmware: Expose psci_get_version through psci_ops structure Will Deacon
2018-01-05 13:12 ` [PATCH v2 06/11] arm64: Move post_ttbr_update_workaround to C code Will Deacon
2018-01-05 13:12 ` [PATCH v2 07/11] arm64: Add skeleton to harden the branch predictor against aliasing attacks Will Deacon
2018-01-08 0:15 ` Jon Masters
2018-01-08 12:16 ` James Morse
2018-01-08 14:26 ` Will Deacon
2018-01-17 4:10 ` Yisheng Xie
2018-01-17 10:07 ` Will Deacon
2018-01-18 8:37 ` Yisheng Xie
2018-01-19 3:37 ` Li Kun
2018-01-19 14:28 ` Will Deacon
2018-01-22 6:52 ` Li Kun
2018-01-05 13:12 ` [PATCH v2 08/11] arm64: KVM: Use per-CPU vector when BP hardening is enabled Will Deacon
2018-01-05 13:12 ` [PATCH v2 09/11] arm64: KVM: Make PSCI_VERSION a fast path Will Deacon
2018-01-05 13:12 ` [PATCH v2 10/11] arm64: cputype: Add missing MIDR values for Cortex-A72 and Cortex-A75 Will Deacon
2018-01-05 13:12 ` [PATCH v2 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs Will Deacon
2018-01-05 14:46 ` James Morse
2018-01-05 14:57 ` Marc Zyngier
2018-01-08 6:31 ` [v2, " Jayachandran C
2018-01-08 6:53 ` [PATCH 1/2] arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs Jayachandran C
2018-01-08 6:53 ` [PATCH 2/2] arm64: Branch predictor hardening for Cavium ThunderX2 Jayachandran C
2018-01-08 16:46 ` Will Deacon
2018-01-08 17:19 ` Jayachandran C
2018-01-08 17:23 ` Will Deacon [this message]
2018-01-09 2:26 ` Jayachandran C
2018-01-09 9:53 ` Will Deacon
2018-01-09 12:47 ` [PATCH v2] " Jayachandran C
2018-01-16 21:50 ` Jon Masters
2018-01-16 21:52 ` Jon Masters
2018-01-16 23:45 ` Jayachandran C
2018-01-17 18:34 ` Jon Masters
2018-01-18 13:53 ` Will Deacon
2018-01-18 17:56 ` Jayachandran C
2018-01-18 18:27 ` Jon Masters
2018-01-18 23:28 ` Jayachandran C
2018-01-19 1:17 ` Jon Masters
2018-01-19 12:22 ` [PATCH v3 1/2] " Jayachandran C
2018-01-19 12:22 ` [PATCH v3 2/2] arm64: Turn on KPTI only on CPUs that need it Jayachandran C
2018-01-22 11:41 ` Will Deacon
2018-01-22 11:51 ` Ard Biesheuvel
2018-01-22 11:55 ` Will Deacon
2018-01-22 18:59 ` Jon Masters
2018-01-19 19:08 ` [PATCH v3 1/2] arm64: Branch predictor hardening for Cavium ThunderX2 Jon Masters
2018-01-22 11:33 ` Will Deacon
2018-01-22 19:00 ` Jon Masters
2018-01-23 9:51 ` Will Deacon
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=20180108172341.GV25869@arm.com \
--to=will.deacon@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=jnair@caviumnetworks.com \
--cc=labbott@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=marc.zyngier@arm.com \
/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).