From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Prasad Sodagudi <psodagud@codeaurora.org>,
Srinivas Ramana <sramana@codeaurora.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Hector Martin <marcan@marcan.st>,
linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
Ajay Patil <pajay@qti.qualcomm.com>,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 00/23] arm64: Early CPU feature override, and applications to VHE, BTI and PAuth
Date: Mon, 08 Feb 2021 15:02:22 +0000 [thread overview]
Message-ID: <240a0245f75d8368a4d90a5e6740dc7d@kernel.org> (raw)
In-Reply-To: <20210208143248.GA25934@willie-the-truck>
Hi Will,
On 2021-02-08 14:32, Will Deacon wrote:
> Hi Marc,
>
> On Mon, Feb 08, 2021 at 09:57:09AM +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.
>
> I applied this locally, but I'm seeing consistent boot failure under
> QEMU when
> KASAN is enabled. I tried sprinkling some __no_sanitize_address
> annotations
> around (see below) but it didn't help. The culprit appears to be
> early_fdt_map(), but looking a bit more closely, I'm really nervous
> about the
> way we call into C functions from __primary_switched. Remember -- this
> code
> runs _twice_ when KASLR is active: before and after the randomization.
> This
> also means that any memory writes the first time around can be lost due
> to
> the D-cache invalidation when (re-)creating the kernel page-tables.
Well, we already call into C functions with KASLR, and nothing explodes
with that, so I must be doing something else wrong.
I do have cache maintenance for the writes to the shadow registers, so
that
part should be fine. But I think I'm missing some cache maintenance
around
the FDT base itself, and I wonder what happens when we go around the
loop.
I'll chase this down now.
Thanks for the heads up.
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Srinivas Ramana <sramana@codeaurora.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Hector Martin <marcan@marcan.st>,
linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
Ajay Patil <pajay@qti.qualcomm.com>,
Prasad Sodagudi <psodagud@codeaurora.org>,
kernel-team@android.com, Ard Biesheuvel <ardb@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 00/23] arm64: Early CPU feature override, and applications to VHE, BTI and PAuth
Date: Mon, 08 Feb 2021 15:02:22 +0000 [thread overview]
Message-ID: <240a0245f75d8368a4d90a5e6740dc7d@kernel.org> (raw)
In-Reply-To: <20210208143248.GA25934@willie-the-truck>
Hi Will,
On 2021-02-08 14:32, Will Deacon wrote:
> Hi Marc,
>
> On Mon, Feb 08, 2021 at 09:57:09AM +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.
>
> I applied this locally, but I'm seeing consistent boot failure under
> QEMU when
> KASAN is enabled. I tried sprinkling some __no_sanitize_address
> annotations
> around (see below) but it didn't help. The culprit appears to be
> early_fdt_map(), but looking a bit more closely, I'm really nervous
> about the
> way we call into C functions from __primary_switched. Remember -- this
> code
> runs _twice_ when KASLR is active: before and after the randomization.
> This
> also means that any memory writes the first time around can be lost due
> to
> the D-cache invalidation when (re-)creating the kernel page-tables.
Well, we already call into C functions with KASLR, and nothing explodes
with that, so I must be doing something else wrong.
I do have cache maintenance for the writes to the shadow registers, so
that
part should be fine. But I think I'm missing some cache maintenance
around
the FDT base itself, and I wonder what happens when we go around the
loop.
I'll chase this down now.
Thanks for the heads up.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Srinivas Ramana <sramana@codeaurora.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Hector Martin <marcan@marcan.st>,
linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
Ajay Patil <pajay@qti.qualcomm.com>,
Prasad Sodagudi <psodagud@codeaurora.org>,
kernel-team@android.com, Ard Biesheuvel <ardb@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 00/23] arm64: Early CPU feature override, and applications to VHE, BTI and PAuth
Date: Mon, 08 Feb 2021 15:02:22 +0000 [thread overview]
Message-ID: <240a0245f75d8368a4d90a5e6740dc7d@kernel.org> (raw)
In-Reply-To: <20210208143248.GA25934@willie-the-truck>
Hi Will,
On 2021-02-08 14:32, Will Deacon wrote:
> Hi Marc,
>
> On Mon, Feb 08, 2021 at 09:57:09AM +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.
>
> I applied this locally, but I'm seeing consistent boot failure under
> QEMU when
> KASAN is enabled. I tried sprinkling some __no_sanitize_address
> annotations
> around (see below) but it didn't help. The culprit appears to be
> early_fdt_map(), but looking a bit more closely, I'm really nervous
> about the
> way we call into C functions from __primary_switched. Remember -- this
> code
> runs _twice_ when KASLR is active: before and after the randomization.
> This
> also means that any memory writes the first time around can be lost due
> to
> the D-cache invalidation when (re-)creating the kernel page-tables.
Well, we already call into C functions with KASLR, and nothing explodes
with that, so I must be doing something else wrong.
I do have cache maintenance for the writes to the shadow registers, so
that
part should be fine. But I think I'm missing some cache maintenance
around
the FDT base itself, and I wonder what happens when we go around the
loop.
I'll chase this down now.
Thanks for the heads up.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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:[~2021-02-08 15:13 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-08 9:57 [PATCH v7 00/23] arm64: Early CPU feature override, and applications to VHE, BTI and PAuth Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 01/23] arm64: Fix labels in el2_setup macros Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 02/23] arm64: Fix outdated TCR setup comment Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 03/23] arm64: Turn the MMU-on sequence into a macro Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 04/23] arm64: Provide an 'upgrade to VHE' stub hypercall Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 05/23] arm64: Initialise as nVHE before switching to VHE Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 06/23] arm64: Drop early setting of MDSCR_EL2.TPMS Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 07/23] arm64: Move VHE-specific SPE setup to mutate_to_vhe() Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 08/23] arm64: Simplify init_el2_state to be non-VHE only Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 09/23] arm64: Move SCTLR_EL1 initialisation to EL-agnostic code Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 10/23] arm64: cpufeature: Add global feature override facility Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 11/23] arm64: cpufeature: Use IDreg override in __read_sysreg_by_encoding() Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 12/23] arm64: Extract early FDT mapping from kaslr_early_init() Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 13/23] arm64: cpufeature: Add an early command-line cpufeature override facility Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 14/23] arm64: Allow ID_AA64MMFR1_EL1.VH to be overridden from the command line Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 15/23] arm64: Honor VHE being disabled from the command-line Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 16/23] arm64: Add an aliasing facility for the idreg override Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 17/23] arm64: Make kvm-arm.mode={nvhe, protected} an alias of id_aa64mmfr1.vh=0 Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 18/23] KVM: arm64: Document HVC_VHE_RESTART stub hypercall Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 19/23] arm64: Move "nokaslr" over to the early cpufeature infrastructure Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 20/23] arm64: cpufeatures: Allow disabling of BTI from the command-line Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 21/23] arm64: Defer enabling pointer authentication on boot core Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 22/23] arm64: cpufeatures: Allow disabling of Pointer Auth from the command-line Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` [PATCH v7 23/23] [DO NOT MERGE] arm64: Cope with CPUs stuck in VHE mode Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-08 9:57 ` Marc Zyngier
2021-02-22 9:35 ` Jonathan Neuschäfer
2021-02-22 9:35 ` Jonathan Neuschäfer
2021-02-22 9:35 ` Jonathan Neuschäfer
2021-02-22 9:47 ` Marc Zyngier
2021-02-22 9:47 ` Marc Zyngier
2021-02-22 9:47 ` Marc Zyngier
2021-02-08 14:32 ` [PATCH v7 00/23] arm64: Early CPU feature override, and applications to VHE, BTI and PAuth Will Deacon
2021-02-08 14:32 ` Will Deacon
2021-02-08 14:32 ` Will Deacon
2021-02-08 14:40 ` Ard Biesheuvel
2021-02-08 14:40 ` Ard Biesheuvel
2021-02-08 14:40 ` Ard Biesheuvel
2021-02-08 15:02 ` Marc Zyngier [this message]
2021-02-08 15:02 ` Marc Zyngier
2021-02-08 15:02 ` Marc Zyngier
2021-02-08 16:30 ` Marc Zyngier
2021-02-08 16:30 ` Marc Zyngier
2021-02-08 16:30 ` Marc Zyngier
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=240a0245f75d8368a4d90a5e6740dc7d@kernel.org \
--to=maz@kernel.org \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=pajay@qti.qualcomm.com \
--cc=psodagud@codeaurora.org \
--cc=sramana@codeaurora.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.