linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>,
	Laura Abbott <labbott@redhat.com>
Subject: Re: [PATCH v2 01/11] arm64: use RET instruction for exiting the trampoline
Date: Mon, 8 Jan 2018 14:33:45 +0000	[thread overview]
Message-ID: <20180108143345.GH25869@arm.com> (raw)
In-Reply-To: <CAKv+Gu-efng1k+QbeKmd2pGz1p4vhoFE4fZ8rZ7bihGvsb-e+w@mail.gmail.com>

On Sat, Jan 06, 2018 at 01:13:23PM +0000, Ard Biesheuvel wrote:
> On 5 January 2018 at 13:12, 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.
> >
> 
> How safe is it to assume that every microarchitecture will behave as
> expected here? Wouldn't it be safer in general not to rely on a memory
> load for x30 in the first place? (see below) Or may the speculative
> execution still branch anywhere even if the branch target is
> guaranteed to be known by that time?

The main problem with this approach is that EL0 can read out the text and
find the kaslr offset. The memory load is fine, because the data page is
unmapped along with the kernel text. I'm not aware of any
micro-architectures where this patch doesn't do what we need.

Will

  reply	other threads:[~2018-01-08 14:33 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 [this message]
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
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=20180108143345.GH25869@arm.com \
    --to=will.deacon@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@linaro.org \
    --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).