From: Mark Brown <broonie@kernel•org>
To: Will Deacon <will@kernel•org>
Cc: Catalin Marinas <catalin.marinas@arm•com>,
linux-arm-kernel@lists•infradead.org,
Suzuki K Poulose <suzuki.poulose@arm•com>
Subject: Re: [PATCH v2 2/2] arm64: Don't use KPTI where we have E0PD
Date: Thu, 15 Aug 2019 19:00:30 +0100 [thread overview]
Message-ID: <20190815180030.GF4841@sirena.co.uk> (raw)
In-Reply-To: <20190815163541.yngqvjmehpuf74ye@willie-the-truck>
[-- Attachment #1.1: Type: text/plain, Size: 1351 bytes --]
On Thu, Aug 15, 2019 at 05:35:42PM +0100, Will Deacon wrote:
> I'm still unsure as to how this works with the kaslr check in
> kpti_install_ng_mappings(). Imagine you have a big.LITTLE system using
> kaslr where the boot CPU has E0PD but the secondary CPU doesn't, and
> requires kpti.
Yes, in fact that is my default big.LITTLE test case.
> In this case, I think we'll:
> 1. Start off with global mappings installed by the boot CPU
> 2. Detect KPTI as being required on the secondary CPU
> 3. Avoid rewriting the page tables because kaslr_offset > 0
> At this point, we've got exposed global mappings on the secondary CPU.
Right, yes. It'd be enormously helpful if KASLR were a bit more visible
in the boot logs or something since I yet again managed to do that bit
of my testing without KASLR actually taking effect :/
> Thinking about this further, I think we can simply move all of the
> 'kaslr_offset() > 0' checks used by the kpti code (i.e. in
> arm64_kernel_unmapped_at_el0(), kpti_install_ng_mappings() and
> unmap_kernel_at_el0()) into a helper function which does the check for
> E0PD as well. Perhaps 'kaslr_requires_kpti()' ?
> I think that should simplify your patch as well. What do you think?
Dunno about simplifying the patch particularly, looks very similar but
in any case it does appear to solve the problem - thanks.
[-- 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
next prev parent reply other threads:[~2019-08-15 18:00 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 [this message]
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
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=20190815180030.GF4841@sirena.co.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