linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] arm64: Add initial support for E0PD
Date: Tue, 13 Aug 2019 18:25:33 +0100	[thread overview]
Message-ID: <20190813172532.hid5cmzhrq7s742l@willie-the-truck> (raw)
In-Reply-To: <20190812125738.17388-2-broonie@kernel.org>

On Mon, Aug 12, 2019 at 01:57:37PM +0100, Mark Brown wrote:
> Kernel Page Table Isolation (KPTI) is used to mitigate some speculation
> based security issues by ensuring that the kernel is not mapped when
> userspace is running but this approach is expensive and is incompatible
> with SPE.  E0PD, introduced in the ARMv8.5 extensions, provides an
> alternative to this which ensures that accesses from userspace to the
> kernel's half of the memory map to always fault with constant time,
> preventing timing attacks without requiring constant unmapping and
> remapping or preventing legitimate accesses.
> 
> This initial patch does not yet integrate with KPTI, this will be dealt
> with in followup patches.  Ideally we could ensure that by default we
> don't use KPTI on CPUs where E0PD is present.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/Kconfig                     | 14 +++++++++++++
>  arch/arm64/include/asm/cpucaps.h       |  3 ++-
>  arch/arm64/include/asm/pgtable-hwdef.h |  2 ++
>  arch/arm64/include/asm/sysreg.h        |  1 +
>  arch/arm64/kernel/cpufeature.c         | 27 ++++++++++++++++++++++++++
>  5 files changed, 46 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index c6a978b0fb7c..3a6875a5bb99 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1409,6 +1409,20 @@ config ARM64_PTR_AUTH
>  
>  endmenu
>  
> +menu "ARMv8.5 architectural features"
> +
> +config ARM64_E0PD
> +	bool "Enable support for E0PD"
> +	default y
> +	help
> +	   E0PD (part of the ARMv8.5 extensions) ensures that EL0
> +	   accesses made via TTBR1 always fault in constant time,
> +	   providing the same guarantees as KPTI with lower overhead.

This could do with a slight tweak, since there are two E0PD bits in the
TCR, which apply to TTBR0 and TTBR1 separately. I'd also be reluctant
to state that it provides the /same/ guarantees as kpti, since I don't
think it will cause a translation fault.

It's probably also worth mentioning that, unlike kpti, E0PDx doesn't
break profiling with SPE.

> +	   This option enables E0PD where available.

For TTBR1.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-08-13 17:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-12 12:57 [0/2] arm64: E0PD support Mark Brown
2019-08-12 12:57 ` [PATCH 1/2] arm64: Add initial support for E0PD Mark Brown
2019-08-13  9:59   ` Suzuki K Poulose
2019-08-13 17:25   ` Will Deacon [this message]
2019-08-12 12:57 ` [PATCH 2/2] arm64: Don't use KPTI where we have E0PD Mark Brown
2019-08-13 10:01   ` Suzuki K Poulose
2019-08-13 17:28   ` Will Deacon
2019-08-13 19:05     ` Mark Brown

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=20190813172532.hid5cmzhrq7s742l@willie-the-truck \
    --to=will@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@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 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).