From: Mark Brown <broonie@kernel•org>
To: Mark Rutland <mark.rutland@arm•com>
Cc: Catalin Marinas <catalin.marinas@arm•com>,
Will Deacon <will@kernel•org>,
linux-arm-kernel@lists•infradead.org,
Suzuki K Poulose <suzuki.poulose@arm•com>
Subject: Re: [PATCH v2 1/2] arm64: Add initial support for E0PD
Date: Fri, 11 Oct 2019 12:17:15 +0100 [thread overview]
Message-ID: <20191011111715.GH4741@sirena.org.uk> (raw)
In-Reply-To: <20191010161317.GD24793@lakrids.cambridge.arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1304 bytes --]
On Thu, Oct 10, 2019 at 05:13:17PM +0100, Mark Rutland wrote:
> So if all the boot-time CPUs have E0PD, we can spawn a VM that starts
> using E0PD, but we might (silently) later migrate it to a CPU without
> E0PD, breaking the security guarantee.
> I think we want this to be STRICT, so that we at least warn in such a
> case.
> More generally than this patch, I suspect we probably want to abort the
> hotplug if we online a CPU that doesn't provide the same gaurantees as
> the sys_val for the field.
Right, if we make it STRICT we at least avoid that issue with KVM.
> > +#ifdef CONFIG_ARM64_E0PD
> > + {
> > + .desc = "E0PD",
> > + .capability = ARM64_HAS_E0PD,
> > + .type = ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE,
> I suspect it would be better to treat this as a system-wide capability,
> as with KPTI, which will make it much easier to reason about.
> That would rule out having E0PD on a subset of CPUs, with or without
> KPTI. With KPTI it's not really necessary, and without KPTI we don't
> have a consistent guarantee, so that sounds reasonable to me.
It does - the main motivation for doing it as a local feature was
to avoid the regression with systems with late CPUs that lack the
capability which Will was concerned about but I'm not sure how
realistic such systems actually are.
[-- 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-10-11 11:17 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 [this message]
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
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=20191011111715.GH4741@sirena.org.uk \
--to=broonie@kernel$(echo .)org \
--cc=catalin.marinas@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=mark.rutland@arm$(echo .)com \
--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