From: Mark Brown <broonie@kernel•org>
To: Suzuki K Poulose <suzuki.poulose@arm•com>
Cc: Catalin Marinas <catalin.marinas@arm•com>,
Will Deacon <will@kernel•org>,
linux-arm-kernel@lists•infradead.org
Subject: Re: [PATCH v2 2/2] arm64: Don't use KPTI where we have E0PD
Date: Thu, 10 Oct 2019 17:04:44 +0100 [thread overview]
Message-ID: <20191010160444.GF4741@sirena.org.uk> (raw)
In-Reply-To: <2d53ed87-34f3-33e1-5501-77895662c47a@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1275 bytes --]
On Thu, Oct 10, 2019 at 11:24:55AM +0100, Suzuki K Poulose wrote:
> On 09/10/2019 18:52, Mark Brown wrote:
> > On Tue, Sep 24, 2019 at 10:13:18AM +0100, Suzuki K Poulose wrote:
> > > Also, we can continue to fail the hotplugged CPUs if we detect that the
> > > pagetables are Global and the new CPU requires nG (for heterogeneous
> > > systems).
> > There's no continuing to reject those CPUs unfortunately, we
> > don't reject anything currently. Any such systems would
> In fact we do reject the hotplugged CPUs, after we have finalised
> the capabilities for KPTI. So, I don't see how the behavior is different.
If we don't have E0PD we will always enable KPTI if we have
enabled KASLR at runtime so a system with late CPUs without E0PD
will boot those CPUs as KPTI will have been enabled from the boot
CPU onwards. When we add E0PD/KASLR integration and change to
only enabling KPTI when we encounter a CPU without E0PD then we
could potentially encounter a system where we no longer enable
KPTI during initial boot due to having E0PD on all the CPUs we
see at that time and then end up rejecting late CPUs which don't
have E0PD. To be honest I'm not sure how realistic this is and
users could work around it by explicitly forcing KPTI but the
potential is there.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2019-10-10 16:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-14 18:31 [PATCH v2 0/2] arm64: E0PD support Mark Brown
2019-08-14 18:31 ` [PATCH v2 1/2] arm64: Add initial support for E0PD Mark Brown
2019-10-10 16:13 ` Mark Rutland
2019-10-11 11:17 ` Mark Brown
2019-10-11 11:40 ` Will Deacon
2019-10-11 12:57 ` Mark Rutland
2019-10-11 12:58 ` Catalin Marinas
2019-10-11 13:46 ` Mark Brown
2019-08-14 18:31 ` [PATCH v2 2/2] arm64: Don't use KPTI where we have E0PD Mark Brown
2019-08-15 16:35 ` Will Deacon
2019-08-15 18:00 ` Mark Brown
2019-08-16 11:31 ` Mark Brown
2019-08-16 10:24 ` Catalin Marinas
2019-08-16 12:10 ` Mark Brown
2019-09-24 9:13 ` Suzuki K Poulose
2019-10-09 17:52 ` Mark Brown
2019-10-10 10:24 ` Suzuki K Poulose
2019-10-10 16:04 ` Mark Brown [this message]
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=20191010160444.GF4741@sirena.org.uk \
--to=broonie@kernel$(echo .)org \
--cc=catalin.marinas@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=suzuki.poulose@arm$(echo .)com \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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