On 31-07-19, 14:09, Julien Thierry wrote:
>
>
> On 12/07/2019 06:28, Viresh Kumar wrote:
> > From: Marc Zyngier <marc.zyngier@xxxxxxx>
> >
> > commit a8e4c0a919ae310944ed2c9ace11cf3ccd8a609b upstream.
> >
> > We call arm64_apply_bp_hardening() from post_ttbr_update_workaround,
> > which has the unexpected consequence of being triggered on every
> > exception return to userspace when ARM64_SW_TTBR0_PAN is selected,
> > even if no context switch actually occured.
> >
> > This is a bit suboptimal, and it would be more logical to only
> > invalidate the branch predictor when we actually switch to
> > a different mm.
> >
> > In order to solve this, move the call to arm64_apply_bp_hardening()
> > into check_and_switch_context(), where we're guaranteed to pick
> > a different mm context.
> >
> > Acked-by: Will Deacon <will.deacon@xxxxxxx>
> > Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx>
> > Signed-off-by: Catalin Marinas <catalin.marinas@xxxxxxx>
> > Signed-off-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
> > ---
> > arch/arm64/mm/context.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
> > index be42bd3dca5c..de5afc27b4e6 100644
> > --- a/arch/arm64/mm/context.c
> > +++ b/arch/arm64/mm/context.c
> > @@ -183,6 +183,8 @@ void check_and_switch_context(struct mm_struct *mm, unsigned int cpu)
> > raw_spin_unlock_irqrestore(&cpu_asid_lock, flags);
> >
> > switch_mm_fastpath:
> > + arm64_apply_bp_hardening();
> > +
> > cpu_switch_mm(mm->pgd, mm);
> > }
> >
> > @@ -193,8 +195,6 @@ asmlinkage void post_ttbr_update_workaround(void)
> > "ic iallu; dsb nsh; isb",
> > ARM64_WORKAROUND_CAVIUM_27456,
> > CONFIG_CAVIUM_ERRATUM_27456));
> > -
> > - arm64_apply_bp_hardening();
>
> Patches 22 and 23 factorize the post_ttbr_update_workaround() and move
> it to C code just so we would and a call to arm64_apply_bp_hardening()
> in patch 24 that now gets moved elsewhere?
>
> Is it really worth backporting patches 22 and 23?
If I can merge patch 24 and 25 into a single patch while backporting,
then patch 22 and 23 won't be required. I am not sure how should the
commit log look like in that case though :)
Is mentioning both the upstream commit ids along with log of the first
patch (which was more important) enough, like this ?
Author: Will Deacon <will.deacon@xxxxxxx>
Date: Wed Jan 3 11:17:58 2018 +0000
arm64: Add skeleton to harden the branch predictor against aliasing attacks
commit 0f15adbb2861ce6f75ccfc5a92b19eae0ef327d0 upstream.
commit a8e4c0a919ae310944ed2c9ace11cf3ccd8a609b upstream.
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@xxxxxxx>
Signed-off-by: Will Deacon <will.deacon@xxxxxxx>
Signed-off-by: Catalin Marinas <catalin.marinas@xxxxxxx>
[ v4.4: Changes made according to 4.4 codebase ]
Signed-off-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
--
viresh
