All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/11] arm64: use RET instruction for exiting the trampoline
Date: Thu, 4 Jan 2018 18:31:59 +0000	[thread overview]
Message-ID: <20180104183158.GM13436@arm.com> (raw)
In-Reply-To: <CAKv+Gu-D763a5OouvmQ_6WfCV-dLgtyHtfT0B1hmrxDX5knD0Q@mail.gmail.com>

Hi Ard,

On Thu, Jan 04, 2018 at 04:24:22PM +0000, Ard Biesheuvel wrote:
> On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
> > Speculation attacks against the entry trampoline can potentially resteer
> > the speculative instruction stream through the indirect branch and into
> > arbitrary gadgets within the kernel.
> >
> > This patch defends against these attacks by forcing a misprediction
> > through the return stack: a dummy BL instruction loads an entry into
> > the stack, so that the predicted program flow of the subsequent RET
> > instruction is to a branch-to-self instruction which is finally resolved
> > as a branch to the kernel vectors with speculation suppressed.
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> >  arch/arm64/kernel/entry.S | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index 031392ee5f47..b9feb587294d 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -1029,6 +1029,9 @@ alternative_else_nop_endif
> >         .if     \regsize == 64
> >         msr     tpidrro_el0, x30        // Restored in kernel_ventry
> >         .endif
> > +       bl      2f
> > +       b       .
> > +2:
> 
> This deserves a comment, I guess?

Yeah, I suppose ;) I'll lift something out of the commit message.

> Also, is deliberately unbalancing the return stack likely to cause
> performance problems, e.g., in libc hot paths?

I don't think so, because it remains balanced after this code. We push an
entry on with the BL and pop it with the RET; the rest of the return stack
remains unchanged. That said, I'm also not sure what we could do differently
here!

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 01/11] arm64: use RET instruction for exiting the trampoline
Date: Thu, 4 Jan 2018 18:31:59 +0000	[thread overview]
Message-ID: <20180104183158.GM13436@arm.com> (raw)
In-Reply-To: <CAKv+Gu-D763a5OouvmQ_6WfCV-dLgtyHtfT0B1hmrxDX5knD0Q@mail.gmail.com>

Hi Ard,

On Thu, Jan 04, 2018 at 04:24:22PM +0000, Ard Biesheuvel wrote:
> On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
> > Speculation attacks against the entry trampoline can potentially resteer
> > the speculative instruction stream through the indirect branch and into
> > arbitrary gadgets within the kernel.
> >
> > This patch defends against these attacks by forcing a misprediction
> > through the return stack: a dummy BL instruction loads an entry into
> > the stack, so that the predicted program flow of the subsequent RET
> > instruction is to a branch-to-self instruction which is finally resolved
> > as a branch to the kernel vectors with speculation suppressed.
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> >  arch/arm64/kernel/entry.S | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index 031392ee5f47..b9feb587294d 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -1029,6 +1029,9 @@ alternative_else_nop_endif
> >         .if     \regsize == 64
> >         msr     tpidrro_el0, x30        // Restored in kernel_ventry
> >         .endif
> > +       bl      2f
> > +       b       .
> > +2:
> 
> This deserves a comment, I guess?

Yeah, I suppose ;) I'll lift something out of the commit message.

> Also, is deliberately unbalancing the return stack likely to cause
> performance problems, e.g., in libc hot paths?

I don't think so, because it remains balanced after this code. We push an
entry on with the BL and pop it with the RET; the rest of the return stack
remains unchanged. That said, I'm also not sure what we could do differently
here!

Will

  reply	other threads:[~2018-01-04 18:31 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-04 15:08 [PATCH 00/11] arm64 kpti hardening and variant 2 workarounds Will Deacon
2018-01-04 15:08 ` Will Deacon
2018-01-04 15:08 ` [PATCH 01/11] arm64: use RET instruction for exiting the trampoline Will Deacon
2018-01-04 15:08   ` Will Deacon
2018-01-04 16:24   ` Ard Biesheuvel
2018-01-04 16:24     ` Ard Biesheuvel
2018-01-04 18:31     ` Will Deacon [this message]
2018-01-04 18:31       ` Will Deacon
2018-01-04 18:35       ` Ard Biesheuvel
2018-01-04 18:35         ` Ard Biesheuvel
2018-01-04 15:08 ` [PATCH 02/11] arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry Will Deacon
2018-01-04 15:08   ` Will Deacon
2018-01-04 15:39   ` Christoph Hellwig
2018-01-04 15:39     ` Christoph Hellwig
2018-01-04 15:08 ` [PATCH 03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3 Will Deacon
2018-01-04 15:08   ` Will Deacon
2018-01-04 23:15   ` Laura Abbott
2018-01-04 23:15     ` Laura Abbott
2018-01-05 10:24   ` Suzuki K Poulose
2018-01-05 10:24     ` Suzuki K Poulose
2018-01-04 15:08 ` [PATCH 04/11] arm64: cpufeature: Pass capability structure to ->enable callback Will Deacon
2018-01-04 15:08   ` Will Deacon
2018-01-05 10:29   ` Suzuki K Poulose
2018-01-05 10:29     ` Suzuki K Poulose
2018-01-04 15:08 ` [PATCH 05/11] drivers/firmware: Expose psci_get_version through psci_ops structure Will Deacon
2018-01-04 15:08   ` Will Deacon
2018-01-04 16:10   ` Lorenzo Pieralisi
2018-01-04 16:10     ` Lorenzo Pieralisi
2018-01-04 15:08 ` [PATCH 06/11] arm64: Move post_ttbr_update_workaround to C code Will Deacon
2018-01-04 15:08   ` Will Deacon
2018-01-04 16:25   ` Ard Biesheuvel
2018-01-04 16:25     ` Ard Biesheuvel
2018-01-04 15:08 ` [PATCH 07/11] arm64: Add skeleton to harden the branch predictor against aliasing attacks Will Deacon
2018-01-04 15:08   ` Will Deacon
2018-01-04 15:08 ` [PATCH 08/11] arm64: KVM: Use per-CPU vector when BP hardening is enabled Will Deacon
2018-01-04 15:08   ` Will Deacon
2018-01-04 16:28   ` Ard Biesheuvel
2018-01-04 16:28     ` Ard Biesheuvel
2018-01-04 17:04     ` Marc Zyngier
2018-01-04 17:04       ` Marc Zyngier
2018-01-04 17:05       ` Ard Biesheuvel
2018-01-04 17:05         ` Ard Biesheuvel
2018-01-04 15:08 ` [PATCH 09/11] arm64: KVM: Make PSCI_VERSION a fast path Will Deacon
2018-01-04 15:08   ` Will Deacon
2018-01-04 15:08 ` [PATCH 10/11] arm64: cputype: Add missing MIDR values for Cortex-A72 and Cortex-A75 Will Deacon
2018-01-04 15:08   ` Will Deacon
2018-01-04 15:08 ` [PATCH 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs Will Deacon
2018-01-04 15:08   ` Will Deacon
2018-01-04 16:31   ` Ard Biesheuvel
2018-01-04 16:31     ` Ard Biesheuvel
2018-01-04 17:14     ` Marc Zyngier
2018-01-04 17:14       ` Marc Zyngier

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=20180104183158.GM13436@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.