From: Marc Zyngier <maz@kernel.org>
To: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Cc: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
kvmarm@lists.linux.dev, oliver.upton@linux.dev,
catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
cohuck@redhat.com, eric.auger@redhat.com, sebott@redhat.com,
yuzenghui@huawei.com, wangzhou1@hisilicon.com,
jiangkunkun@huawei.com, jonathan.cameron@huawei.com,
anthony.jebson@huawei.com, linux-arm-kernel@lists.infradead.org,
linuxarm@huawei.com
Subject: Re: [BUG][PATCH v8 4/6] arm64: Make _midr_in_range_list() an exported function
Date: Tue, 15 Apr 2025 16:26:53 +0100 [thread overview]
Message-ID: <865xj5la2q.wl-maz@kernel.org> (raw)
In-Reply-To: <3d97e45a-23cf-419b-9b6f-140b4d88de7b@arm.com>
On Tue, 15 Apr 2025 11:57:50 +0100,
Ada Couprie Diaz <ada.coupriediaz@arm.com> wrote:
>
> Hello,
>
> I discovered that this patch breaks boot for some CPUs when building
> the default defconfig plus KASAN. This is still the case in v6.15-rc1
> and rc2.
>
> This patch marks `is_midr_in_range_list` as position independent but
> it isn't, breaking early boot when instrumented with KASAN and
> `CONFIG_RANDOMIZE_BASE` enabled.
>
> The breaking usage seems to be in `kaslr_requires_kpti()` called in
> `early_map_kernel()`.
> My testing on an AMD Seattle board does crash, but newer machines
> implementing E0PD do not crash as they do not need to check MIDRs in
> `kaslr_requires_kpti()`.
> `is_mdr_in_range_list` did work in PI code previously because it was
> `inline`, which this patch changes.
OK, this is much more of a pain than I thought.
I tried bringing the various helpers into the PI section, but it ended
up being extremely ugly.
More importantly, this is something that is pretty much at odds with
the whole idea of the MIDR override -- it happens way earlier than we
can populate the table.
The thing is, the only reason we need to do this is that we need to
support the Cavium SEFAC (Sorry Excuse For A Computer) that cannot run
with KPTI.
I can restore harmony with the following hack. But maybe we should
just prune TX from the kernel and be done with this contraption.
M.
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index d1cc0571798bf..bdfefca166baa 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -292,6 +292,20 @@ static inline bool midr_is_cpu_model_range(u32 midr, u32 model, u32 rv_min,
return _model == model && rv >= rv_min && rv <= rv_max;
}
+static inline bool __is_midr_in_range(struct midr_range const *range)
+{
+ return midr_is_cpu_model_range(read_cpuid_id(), range->model,
+ range->rv_min, range->rv_max);
+}
+
+static inline bool __is_midr_in_range_list(struct midr_range const *ranges)
+{
+ while (ranges->model)
+ if (__is_midr_in_range(ranges++))
+ return true;
+ return false;
+}
+
struct target_impl_cpu {
u64 midr;
u64 revidr;
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 30a29e88994ba..e54a384826dc1 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -72,6 +72,17 @@ extern void create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
extern void *fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot);
extern void mark_linear_text_alias_ro(void);
+static inline bool cpu_has_e0pd(void)
+{
+ if (IS_ENABLED(CONFIG_ARM64_E0PD)) {
+ u64 mmfr2 = read_sysreg_s(SYS_ID_AA64MMFR2_EL1);
+ return (cpuid_feature_extract_unsigned_field(mmfr2,
+ ID_AA64MMFR2_EL1_E0PD_SHIFT));
+ }
+
+ return false;
+}
+
/*
* This check is triggered during the early boot before the cpufeature
* is initialised. Checking the status on the local CPU allows the boot
@@ -87,12 +98,8 @@ static inline bool kaslr_requires_kpti(void)
* E0PD does a similar job to KPTI so can be used instead
* where available.
*/
- if (IS_ENABLED(CONFIG_ARM64_E0PD)) {
- u64 mmfr2 = read_sysreg_s(SYS_ID_AA64MMFR2_EL1);
- if (cpuid_feature_extract_unsigned_field(mmfr2,
- ID_AA64MMFR2_EL1_E0PD_SHIFT))
- return false;
- }
+ if (cpu_has_e0pd())
+ return false;
/*
* Systems affected by Cavium erratum 24756 are incompatible
@@ -108,5 +115,21 @@ static inline bool kaslr_requires_kpti(void)
return true;
}
+/* Same as the above, but limited to the local CPU, ignoring the MIDR list */
+static inline bool __kaslr_requires_kpti(void)
+{
+ if (cpu_has_e0pd())
+ return false;
+
+ if (IS_ENABLED(CONFIG_CAVIUM_ERRATUM_27456)) {
+ extern const struct midr_range cavium_erratum_27456_cpus[];
+
+ if (__is_midr_in_range_list(cavium_erratum_27456_cpus))
+ return false;
+ }
+
+ return true;
+}
+
#endif /* !__ASSEMBLY__ */
#endif
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index b55f5f7057502..ba8e05d640c7e 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -32,8 +32,7 @@ static inline bool is_midr_in_range(struct midr_range const *range)
int i;
if (!target_impl_cpu_num)
- return midr_is_cpu_model_range(read_cpuid_id(), range->model,
- range->rv_min, range->rv_max);
+ return __is_midr_in_range(range);
for (i = 0; i < target_impl_cpu_num; i++) {
if (midr_is_cpu_model_range(target_impl_cpus[i].midr,
diff --git a/arch/arm64/kernel/pi/map_kernel.c b/arch/arm64/kernel/pi/map_kernel.c
index e57b043f324b5..2df76d44a1072 100644
--- a/arch/arm64/kernel/pi/map_kernel.c
+++ b/arch/arm64/kernel/pi/map_kernel.c
@@ -245,7 +245,7 @@ asmlinkage void __init early_map_kernel(u64 boot_status, void *fdt)
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
u64 kaslr_seed = kaslr_early_init(fdt, chosen);
- if (kaslr_seed && kaslr_requires_kpti())
+ if (kaslr_seed && __kaslr_requires_kpti())
arm64_use_ng_mappings = true;
kaslr_offset |= kaslr_seed & ~(MIN_KIMG_ALIGN - 1);
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-04-15 15:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-21 14:02 [PATCH v8 0/6] KVM: arm64: Errata management for VM Live migration Shameer Kolothum
2025-02-21 14:02 ` [PATCH v8 1/6] arm64: Modify _midr_range() functions to read MIDR/REVIDR internally Shameer Kolothum
2025-02-26 19:39 ` Catalin Marinas
2025-02-21 14:02 ` [PATCH v8 2/6] KVM: arm64: Introduce hypercall support for retrieving target implementations Shameer Kolothum
2025-02-21 14:02 ` [PATCH v8 3/6] KVM: arm64: Introduce KVM_REG_ARM_VENDOR_HYP_BMAP_2 Shameer Kolothum
2025-02-21 14:02 ` [PATCH v8 4/6] arm64: Make _midr_in_range_list() an exported function Shameer Kolothum
2025-02-26 19:40 ` Catalin Marinas
2025-04-15 10:57 ` [BUG][PATCH " Ada Couprie Diaz
2025-04-15 15:18 ` Shameerali Kolothum Thodi
2025-04-15 15:26 ` Marc Zyngier [this message]
2025-04-15 15:54 ` Catalin Marinas
2025-04-15 16:47 ` Marc Zyngier
2025-02-21 14:02 ` [PATCH v8 5/6] smccc/kvm_guest: Enable errata based on implementation CPUs Shameer Kolothum
2025-02-26 19:41 ` Catalin Marinas
2025-02-21 14:02 ` [PATCH v8 6/6] KVM: selftests: Add test for KVM_REG_ARM_VENDOR_HYP_BMAP_2 Shameer Kolothum
2025-03-05 23:58 ` [PATCH v8 0/6] KVM: arm64: Errata management for VM Live migration Oliver Upton
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=865xj5la2q.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=ada.coupriediaz@arm.com \
--cc=anthony.jebson@huawei.com \
--cc=catalin.marinas@arm.com \
--cc=cohuck@redhat.com \
--cc=eric.auger@redhat.com \
--cc=jiangkunkun@huawei.com \
--cc=jonathan.cameron@huawei.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linuxarm@huawei.com \
--cc=mark.rutland@arm.com \
--cc=oliver.upton@linux.dev \
--cc=sebott@redhat.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=wangzhou1@hisilicon.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).