All of lore.kernel.org
 help / color / mirror / Atom feed
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER)
Date: Fri, 17 Nov 2017 16:19:35 -0800	[thread overview]
Message-ID: <20171118001935.GB18379@codeaurora.org> (raw)
In-Reply-To: <1510942921-12564-1-git-send-email-will.deacon@arm.com>

On 11/17, Will Deacon wrote:
> Hi all,
> 
> This patch series implements something along the lines of KAISER for arm64:
> 
>   https://gruss.cc/files/kaiser.pdf
> 
> although I wrote this from scratch because the paper has some funny
> assumptions about how the architecture works. There is a patch series
> in review for x86, which follows a similar approach:
> 
>   http://lkml.kernel.org/r/<20171110193058.BECA7D88@viggo.jf.intel.com>
> 
> and the topic was recently covered by LWN (currently subscriber-only):
> 
>   https://lwn.net/Articles/738975/
> 
> The basic idea is that transitions to and from userspace are proxied
> through a trampoline page which is mapped into a separate page table and
> can switch the full kernel mapping in and out on exception entry and
> exit respectively. This is a valuable defence against various KASLR and
> timing attacks, particularly as the trampoline page is at a fixed virtual
> address and therefore the kernel text can be randomized independently.
> 
> The major consequences of the trampoline are:
> 
>   * We can no longer make use of global mappings for kernel space, so
>     each task is assigned two ASIDs: one for user mappings and one for
>     kernel mappings
> 
>   * Our ASID moves into TTBR1 so that we can quickly switch between the
>     trampoline and kernel page tables
> 
>   * Switching TTBR0 always requires use of the zero page, so we can
>     dispense with some of our errata workaround code.
> 
>   * entry.S gets more complicated to read
> 
> The performance hit from this series isn't as bad as I feared: things
> like cyclictest and kernbench seem to be largely unaffected, although
> syscall micro-benchmarks appear to show that syscall overhead is roughly
> doubled, and this has an impact on things like hackbench which exhibits
> a ~10% hit due to its heavy context-switching.

Do you have performance benchmark numbers on CPUs with the Falkor
errata? I'm interested to see how much the TLB invalidate hurts
heavy context-switching workloads on these CPUs.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@codeaurora.org>
To: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
	mark.rutland@arm.com, ard.biesheuvel@linaro.org,
	dave.hansen@linux.intel.com, keescook@chromium.org
Subject: Re: [PATCH 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER)
Date: Fri, 17 Nov 2017 16:19:35 -0800	[thread overview]
Message-ID: <20171118001935.GB18379@codeaurora.org> (raw)
In-Reply-To: <1510942921-12564-1-git-send-email-will.deacon@arm.com>

On 11/17, Will Deacon wrote:
> Hi all,
> 
> This patch series implements something along the lines of KAISER for arm64:
> 
>   https://gruss.cc/files/kaiser.pdf
> 
> although I wrote this from scratch because the paper has some funny
> assumptions about how the architecture works. There is a patch series
> in review for x86, which follows a similar approach:
> 
>   http://lkml.kernel.org/r/<20171110193058.BECA7D88@viggo.jf.intel.com>
> 
> and the topic was recently covered by LWN (currently subscriber-only):
> 
>   https://lwn.net/Articles/738975/
> 
> The basic idea is that transitions to and from userspace are proxied
> through a trampoline page which is mapped into a separate page table and
> can switch the full kernel mapping in and out on exception entry and
> exit respectively. This is a valuable defence against various KASLR and
> timing attacks, particularly as the trampoline page is at a fixed virtual
> address and therefore the kernel text can be randomized independently.
> 
> The major consequences of the trampoline are:
> 
>   * We can no longer make use of global mappings for kernel space, so
>     each task is assigned two ASIDs: one for user mappings and one for
>     kernel mappings
> 
>   * Our ASID moves into TTBR1 so that we can quickly switch between the
>     trampoline and kernel page tables
> 
>   * Switching TTBR0 always requires use of the zero page, so we can
>     dispense with some of our errata workaround code.
> 
>   * entry.S gets more complicated to read
> 
> The performance hit from this series isn't as bad as I feared: things
> like cyclictest and kernbench seem to be largely unaffected, although
> syscall micro-benchmarks appear to show that syscall overhead is roughly
> doubled, and this has an impact on things like hackbench which exhibits
> a ~10% hit due to its heavy context-switching.

Do you have performance benchmark numbers on CPUs with the Falkor
errata? I'm interested to see how much the TLB invalidate hurts
heavy context-switching workloads on these CPUs.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  parent reply	other threads:[~2017-11-18  0:19 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-17 18:21 [PATCH 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER) Will Deacon
2017-11-17 18:21 ` Will Deacon
2017-11-17 18:21 ` [PATCH 01/18] arm64: mm: Use non-global mappings for kernel space Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 02/18] arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 03/18] arm64: mm: Move ASID from TTBR0 to TTBR1 Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 04/18] arm64: mm: Remove pre_ttbr0_update_workaround for Falkor erratum #E1003 Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 05/18] arm64: mm: Rename post_ttbr0_update_workaround Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 06/18] arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 07/18] arm64: mm: Allocate ASIDs in pairs Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 08/18] arm64: mm: Add arm64_kernel_mapped_at_el0 helper using static key Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 09/18] arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 10/18] arm64: entry: Add exception trampoline page for exceptions from EL0 Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 11/18] arm64: mm: Map entry trampoline into trampoline and kernel page tables Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 12/18] arm64: entry: Explicitly pass exception level to kernel_ventry macro Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 13/18] arm64: entry: Hook up entry trampoline to exception vectors Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 14/18] arm64: erratum: Work around Falkor erratum #E1003 in trampoline code Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-18  0:27   ` Stephen Boyd
2017-11-18  0:27     ` Stephen Boyd
2017-11-20 18:05     ` Will Deacon
2017-11-20 18:05       ` Will Deacon
2017-11-17 18:21 ` [PATCH 15/18] arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:21 ` [PATCH 16/18] arm64: entry: Add fake CPU feature for mapping the kernel at EL0 Will Deacon
2017-11-17 18:21   ` Will Deacon
2017-11-17 18:22 ` [PATCH 17/18] arm64: makefile: Ensure TEXT_OFFSET doesn't overlap with trampoline Will Deacon
2017-11-17 18:22   ` Will Deacon
2017-11-17 18:22 ` [PATCH 18/18] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0 Will Deacon
2017-11-17 18:22   ` Will Deacon
2017-11-22 16:52   ` Marc Zyngier
2017-11-22 16:52     ` Marc Zyngier
2017-11-22 19:36     ` Will Deacon
2017-11-22 19:36       ` Will Deacon
2017-11-18  0:19 ` Stephen Boyd [this message]
2017-11-18  0:19   ` [PATCH 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER) Stephen Boyd
2017-11-20 18:03   ` Will Deacon
2017-11-20 18:03     ` Will Deacon
2017-11-18 15:25 ` Ard Biesheuvel
2017-11-18 15:25   ` Ard Biesheuvel
2017-11-20 18:06   ` Will Deacon
2017-11-20 18:06     ` Will Deacon
2017-11-20 18:20     ` Ard Biesheuvel
2017-11-20 18:20       ` Ard Biesheuvel
2017-11-22 19:37       ` Will Deacon
2017-11-22 19:37         ` Will Deacon
2017-11-20 22:50 ` Laura Abbott
2017-11-20 22:50   ` Laura Abbott
2017-11-22 19:37   ` Will Deacon
2017-11-22 19:37     ` Will Deacon
2017-11-22 16:19 ` Pavel Machek
2017-11-22 16:19   ` Pavel Machek
2017-11-22 19:37   ` Will Deacon
2017-11-22 19:37     ` Will Deacon
2017-11-22 22:36     ` Pavel Machek
2017-11-22 22:36       ` Pavel Machek
2017-11-22 21:19   ` Ard Biesheuvel
2017-11-22 21:19     ` Ard Biesheuvel
2017-11-22 22:33     ` Pavel Machek
2017-11-22 22:33       ` Pavel Machek
2017-11-22 23:19       ` Ard Biesheuvel
2017-11-22 23:19         ` Ard Biesheuvel
2017-11-22 23:37         ` Pavel Machek
2017-11-22 23:37           ` Pavel Machek
2017-11-23  6:51           ` Ard Biesheuvel
2017-11-23  6:51             ` Ard Biesheuvel
2017-11-23  9:07             ` Pavel Machek
2017-11-23  9:07               ` Pavel Machek
2017-11-23  9:23               ` Ard Biesheuvel
2017-11-23  9:23                 ` Ard Biesheuvel
2017-11-23 10:46                 ` Pavel Machek
2017-11-23 10:46                   ` Pavel Machek
2017-11-23 11:38                   ` Ard Biesheuvel
2017-11-23 11:38                     ` Ard Biesheuvel
2017-11-23 17:54                     ` Pavel Machek
2017-11-23 17:54                       ` Pavel Machek
2017-11-23 18:17                       ` Ard Biesheuvel
2017-11-23 18:17                         ` Ard Biesheuvel

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=20171118001935.GB18379@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --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.