Alex,
On 31/01/18 05:57, Alex Shi wrote:
CC Marc Zyngier marc.zyngier@arm.com
On 01/31/2018 12:05 AM, Alex Shi wrote:
Aliasing attacks against CPU branch predictors can allow an attacker to redirect speculative control flow on some CPUs and potentially divulge information from one context to another.
This patch adds initial skeleton code behind a new Kconfig option to enable implementation-specific mitigations against these attacks for CPUs that are affected.
Co-developed-by: Marc Zyngier marc.zyngier@arm.com Signed-off-by: Will Deacon will.deacon@arm.com (cherry picked from commit 7bd293b6845d003ab087faa6515a626c8703b8da) Signed-off-by: Alex Shi alex.shi@linaro.org
Conflicts: expand enable_da_f in entry.S use 5 parameters ARM64_FTR_BITS() add percpu.h in mm_types.h for percpu functions use cpus_have_cap instead of cpus_have_const_cap
<snip>...
+#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR +#include <asm/mmu_context.h> +#include <asm/cacheflush.h>
+DEFINE_PER_CPU_READ_MOSTLY(struct bp_hardening_data, bp_hardening_data);
+#ifdef CONFIG_KVM +static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
const char *hyp_vecs_end)
+{
- void *dst = lm_alias(__bp_harden_hyp_vecs_start + slot * SZ_2K)
Hi Will,
Here lm_alias get the virtual address of __bp_harden_hyp_vecs_start from 0xffff000008098800(for example) to 0xffff800008098800 Code basing on v4.15-rc3 works well for this new address 0xffff80000.... but code basing on v4.9 will report null page:
Unable to handle kernel paging request at virtual address ffff8000000....
And without the lm_alias, the kernel booted well. Another place used lm_alias is in kvm_get_hyp_vector(),
Is this safe to drop lm_alias? Or is there some place to request pages for aliaed adderss?
The question you have to ask yourself is whether or not the address you're getting for __bp_harden_hyp_vecs_start is from the linear mapping or from another range. If the former, lm_alias is not necessary (but you may want to find out why it gives you something that is unexpected). If the latter, then you really need to translate it to the linear map, as you're not going to be able to write to kernel text via its execution mapping.
As for kvm_get_hyp_vector, same thing. We only map the linear map at EL2, so you really need to pick the right set of VAs, or kern_hyp_va is going to point you to lalaland (and that will be pretty final).
I cannot page 4.9 in at the moment, but some limited investigation should help you finding out how we used to map the kernel last year.
Thanks,
M.