On Mon, Feb 07, 2022 at 03:20:32PM +0000, Mark Brown wrote:
> Since all the fields in the main ID registers are 4 bits wide we have up
> until now not bothered specifying the width in the code. Since we now
> wish to use this mechanism to enumerate features from the floating point
> feature registers which do not follow this pattern add a width to the
> table. This means updating all the existing table entries but makes it
> less likely that we run into issues in future due to implicitly assuming
> a 4 bit width.
>
> Signed-off-by: Mark Brown <broonie@xxxxxxxxxx>
Do we leave this one alone on purpose?
.desc = "GIC system register CPU interface",
.capability = ARM64_HAS_SYSREG_GIC_CPUIF,
.type = ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE,
.matches = has_useable_gicv3_cpuif,
.sys_reg = SYS_ID_AA64PFR0_EL1,
.field_pos = ID_AA64PFR0_GIC_SHIFT,
.sign = FTR_UNSIGNED,
.min_field_value = 1,
Since width == 0, it will generate an undefined behavior.
UBSAN: shift-out-of-bounds in ./arch/arm64/include/asm/cpufeature.h:535:49
shift exponent 64 is too large for 64-bit type 'long long unsigned int'
CPU: 0 PID: 0 Comm: swapper Not tainted 5.17.0-rc6-next-20220301 #1
Call trace:
dump_backtrace
show_stack
dump_stack_lvl
dump_stack
ubsan_epilogue
__ubsan_handle_shift_out_of_bounds
has_cpuid_feature
cpuid_feature_extract_unsigned_field_width at arch/arm64/include/asm/cpufeature.h:535
(inlined by) cpuid_feature_extract_field_width at arch/arm64/include/asm/cpufeature.h:582
(inlined by) cpuid_feature_extract_field_width at arch/arm64/include/asm/cpufeature.h:578
(inlined by) feature_matches at arch/arm64/kernel/cpufeature.c:1317
(inlined by) has_cpuid_feature at arch/arm64/kernel/cpufeature.c:1335
has_useable_gicv3_cpuif
has_useable_gicv3_cpuif at arch/arm64/kernel/cpufeature.c:1389
update_cpu_capabilities
init_cpu_features
cpuinfo_store_boot_cpu
smp_prepare_boot_cpu
start_kernel
__primary_switched
