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