From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: catalin.marinas@arm.com, kernel-team@android.com,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v2 7/9] KVM: arm64: Allocate hyp vectors statically
Date: Thu, 12 Nov 2020 11:07:55 +0000 [thread overview]
Message-ID: <f26c82b8bbb75904d7b8cf9ce84a507e@kernel.org> (raw)
In-Reply-To: <20201109214726.15276-8-will@kernel.org>
On 2020-11-09 21:47, Will Deacon wrote:
> The EL2 vectors installed when a guest is running point at one of the
> following configurations for a given CPU:
>
> - Straight at __kvm_hyp_vector
> - A trampoline containing an SMC sequence to mitigate Spectre-v2 and
> then a direct branch to __kvm_hyp_vector
> - A dynamically-allocated trampoline which has an indirect branch to
> __kvm_hyp_vector
> - A dynamically-allocated trampoline containing an SMC sequence to
> mitigate Spectre-v2 and then an indirect branch to __kvm_hyp_vector
>
> The indirect branches mean that VA randomization at EL2 isn't trivially
> bypassable using Spectre-v3a (where the vector base is readable by the
> guest).
>
> Rather than populate these vectors dynamically, configure everything
> statically and use an enumerated type to identify the vector "slot"
> corresponding to one of the configurations above. This both simplifies
> the code, but also makes it much easier to implement at EL2 later on.
This series terminally breaks VHE (the host locks up on the first guest
run, CPU is nowhere to be seen again).
I have a hunch about what is happening, see below.
[...]
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 044c5fc81f90..ec6dce70c611 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -51,14 +51,6 @@ DECLARE_KVM_HYP_PER_CPU(unsigned long,
> kvm_hyp_vector);
> static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
> unsigned long kvm_arm_hyp_percpu_base[NR_CPUS];
>
> -/* Hypervisor VA of the indirect vector trampoline page */
> -static void *__kvm_bp_vect_base;
> -/*
> - * Slot in the hyp vector page for use by the indirect vector
> trampoline
> - * when mitigation against Spectre-v2 is not required.
> - */
> -static int __kvm_harden_el2_vector_slot;
> -
> /* The VMID used in the VTTBR */
> static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1);
> static u32 kvm_next_vmid;
> @@ -1303,33 +1295,36 @@ static unsigned long nvhe_percpu_order(void)
> return size ? get_order(size) : 0;
> }
>
> -static int kvm_map_vectors(void)
> +/* A lookup table holding the hypervisor VA for each vector slot */
> +static void *hyp_spectre_vector_selector[BP_HARDEN_EL2_SLOTS];
> +
> +static void kvm_init_vector_slot(void *base, enum
> arm64_hyp_spectre_vector slot)
> {
> - int slot;
> + hyp_spectre_vector_selector[slot] = base + (slot * SZ_2K);
> +}
> +
> +static int kvm_init_vector_slots(void)
> +{
> + int err;
> + void *base;
> +
> + base = kern_hyp_va(kvm_ksym_ref(__kvm_hyp_vector));
> + kvm_init_vector_slot(base, HYP_VECTOR_DIRECT);
> +
> + base = kern_hyp_va(kvm_ksym_ref(__bp_harden_hyp_vecs));
> + kvm_init_vector_slot(base, HYP_VECTOR_SPECTRE_DIRECT);
>
> - /*
> - * SV2 = ARM64_SPECTRE_V2
> - * HEL2 = ARM64_HARDEN_EL2_VECTORS
> - *
> - * !SV2 + !HEL2 -> use direct vectors
> - * SV2 + !HEL2 -> use hardened vectors in place
> - * !SV2 + HEL2 -> allocate one vector slot and use exec mapping
> - * SV2 + HEL2 -> use hardened vectors and use exec mapping
> - */
> if (!cpus_have_const_cap(ARM64_HARDEN_EL2_VECTORS))
> return 0;
>
> - /*
> - * Always allocate a spare vector slot, as we don't know yet which
> CPUs
> - * have a BP hardening slot that we can reuse.
> - */
> - slot = atomic_inc_return(&arm64_el2_vector_last_slot);
> - BUG_ON(slot >= BP_HARDEN_EL2_SLOTS);
> - __kvm_harden_el2_vector_slot = slot;
> + err = create_hyp_exec_mappings(__pa_symbol(__bp_harden_hyp_vecs),
> + __BP_HARDEN_HYP_VECS_SZ, &base);
> + if (err)
> + return err;
>
> - return create_hyp_exec_mappings(__pa_symbol(__bp_harden_hyp_vecs),
> - __BP_HARDEN_HYP_VECS_SZ,
> - &__kvm_bp_vect_base);
> + kvm_init_vector_slot(base, HYP_VECTOR_INDIRECT);
> + kvm_init_vector_slot(base, HYP_VECTOR_SPECTRE_INDIRECT);
> + return 0;
> }
>
> static void cpu_init_hyp_mode(void)
> @@ -1406,24 +1401,9 @@ static void cpu_hyp_reset(void)
> static void cpu_set_hyp_vector(void)
> {
> struct bp_hardening_data *data = this_cpu_ptr(&bp_hardening_data);
> - void *vect = kern_hyp_va(kvm_ksym_ref(__kvm_hyp_vector));
> - int slot = -1;
> -
> - if (cpus_have_const_cap(ARM64_SPECTRE_V2) && data->fn) {
> - vect = kern_hyp_va(kvm_ksym_ref(__bp_harden_hyp_vecs));
> - slot = data->hyp_vectors_slot;
> - }
> -
> - if (this_cpu_has_cap(ARM64_HARDEN_EL2_VECTORS) && !has_vhe()) {
> - vect = __kvm_bp_vect_base;
> - if (slot == -1)
> - slot = __kvm_harden_el2_vector_slot;
> - }
> -
> - if (slot != -1)
> - vect += slot * SZ_2K;
> + void *vector = hyp_spectre_vector_selector[data->slot];
>
> - *this_cpu_ptr_hyp_sym(kvm_hyp_vector) = (unsigned long)vect;
> + *this_cpu_ptr_hyp_sym(kvm_hyp_vector) = (unsigned long)vector;
> }
>
> static void cpu_hyp_reinit(void)
> @@ -1661,9 +1641,9 @@ static int init_hyp_mode(void)
> goto out_err;
> }
>
> - err = kvm_map_vectors();
> + err = kvm_init_vector_slots();
Here, you have turned the mapping of the vectors into the full
init+map. The mapping makes no sense on VHE, but the initialization
does matter! init_hyp_mode() being only called on non-VHE, the HYP
vectors are never initialized. Too bad.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2020-11-12 11:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-09 21:47 [PATCH v2 0/9] Rework hyp vector handling Will Deacon
2020-11-09 21:47 ` [PATCH v2 1/9] KVM: arm64: Remove redundant Spectre-v2 code from kvm_map_vector() Will Deacon
2020-11-09 21:47 ` [PATCH v2 2/9] KVM: arm64: Tidy up kvm_map_vector() Will Deacon
2020-11-09 21:47 ` [PATCH v2 3/9] KVM: arm64: Move kvm_get_hyp_vector() out of header file Will Deacon
2020-11-09 21:47 ` [PATCH v2 4/9] KVM: arm64: Make BP hardening globals static instead Will Deacon
2020-11-09 21:47 ` [PATCH v2 5/9] KVM: arm64: Move BP hardening helpers into spectre.h Will Deacon
2020-11-09 21:47 ` [PATCH v2 6/9] KVM: arm64: Re-jig logic when patching hardened hyp vectors Will Deacon
2020-11-09 21:47 ` [PATCH v2 7/9] KVM: arm64: Allocate hyp vectors statically Will Deacon
2020-11-12 11:07 ` Marc Zyngier [this message]
2020-11-12 11:27 ` Will Deacon
2020-11-12 12:05 ` Marc Zyngier
2020-11-12 12:24 ` Will Deacon
2020-11-09 21:47 ` [PATCH v2 8/9] arm64: spectre: Rename ARM64_HARDEN_EL2_VECTORS to ARM64_SPECTRE_V3A Will Deacon
2020-11-09 21:47 ` [PATCH v2 9/9] arm64: spectre: Consolidate spectre-v3a detection 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=f26c82b8bbb75904d7b8cf9ce84a507e@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--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