[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210118145434.2lar7xkgwy5yj54i@google.com>
Date: Mon, 18 Jan 2021 14:54:34 +0000
From: David Brazdil <dbrazdil@...gle.com>
To: Marc Zyngier <maz@...nel.org>
Cc: linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu,
linux-kernel@...r.kernel.org,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexandru Elisei <alexandru.elisei@....com>,
Ard Biesheuvel <ardb@...nel.org>,
Jing Zhang <jingzhangos@...gle.com>,
Ajay Patil <pajay@....qualcomm.com>,
Prasad Sodagudi <psodagud@...eaurora.org>,
Srinivas Ramana <sramana@...eaurora.org>,
James Morse <james.morse@....com>,
Julien Thierry <julien.thierry.kdev@...il.com>,
Suzuki K Poulose <suzuki.poulose@....com>,
kernel-team@...roid.com
Subject: Re: [PATCH v4 00/21] arm64: Early CPU feature override, and
applications to VHE, BTI and PAuth
On Mon, Jan 18, 2021 at 09:45:12AM +0000, Marc Zyngier wrote:
> It recently came to light that there is a need to be able to override
> some CPU features very early on, before the kernel is fully up and
> running. The reasons for this range from specific feature support
> (such as using Protected KVM on VHE HW, which is the main motivation
> for this work) to errata workaround (a feature is broken on a CPU and
> needs to be turned off, or rather not enabled).
>
> This series tries to offer a limited framework for this kind of
> problems, by allowing a set of options to be passed on the
> command-line and altering the feature set that the cpufeature
> subsystem exposes to the rest of the kernel. Note that this doesn't
> change anything for code that directly uses the CPU ID registers.
>
> The series completely changes the way a VHE-capable system boots, by
> *always* booting non-VHE first, and then upgrading to VHE when deemed
> capable. Although it sounds scary, this is actually simple to
> implement (and I wish I had done that five years ago). The "upgrade to
> VHE" path is then conditioned on the VHE feature not being disabled
> from the command-line.
>
> Said command-line parsing borrows a lot from the kaslr code, and
> subsequently allows the "nokaslr" option to be moved to the new
> infrastructure (though it all looks a bit... odd).
>
> Further patches now add support for disabling BTI and PAuth, the
> latter being based on an initial series by Srinivas Ramana[0]. There
> is some ongoing discussions about being able to disable MTE, but no
> clear resolution on that subject yet.
>
> This has been tested on multiple VHE and non-VHE systems.
>
> * From v3 [3]:
> - Fixed the VHE_RESTART stub (duh!)
> - Switched to using arm64_ftr_safe_value() instead of the user
> provided value
> - Per-feature override warning
>
> * From v2 [2]:
> - Simplify the VHE_RESTART stub
> - Fixed a number of spelling mistakes, and hopefully introduced a
> few more
> - Override features in __read_sysreg_by_encoding()
> - Allow both BTI and PAuth to be overridden on the command line
> - Rebased on -rc3
>
> * From v1 [1]:
> - Fix SPE init on VHE when EL2 doesn't own SPE
> - Fix re-init when KASLR is used
> - Handle the resume path
> - Rebased to 5.11-rc2
>
> [0] https://lore.kernel.org/r/1610152163-16554-1-git-send-email-sramana@codeaurora.org
> [1] https://lore.kernel.org/r/20201228104958.1848833-1-maz@kernel.org
> [2] https://lore.kernel.org/r/20210104135011.2063104-1-maz@kernel.org
> [3] https://lore.kernel.org/r/20210111132811.2455113-1-maz@kernel.org
Pretty cool! Left a few minor comments here and there, other than that:
Acked-by: David Brazdil <dbrazdil@...gle.com>
Powered by blists - more mailing lists