+56
−0
Loading
maillist inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I8EC9K CVE: NA Reference: https://lore.kernel.org/linux-arm-kernel/20240613061731.3109448-1-anshuman.khandual@arm.com/ -------------------------------- The Branch Record Buffer Extension (BRBE) adds a number of system registers and instructions, which we don't currently intend to expose to guests. Our existing logic handles this safely, but this could be improved with some explicit handling of BRBE. The presence of BRBE is currently hidden from guests as the cpufeature code's ftr_id_aa64dfr0[] table doesn't have an entry for the BRBE field, and so this will be zero in the sanitised value of ID_AA64DFR0 exposed to guests via read_sanitised_id_aa64dfr0_el1(). As the ftr_id_aa64dfr0[] table may gain an entry for the BRBE field in future, for robustness we should explicitly mask out the BRBE field in read_sanitised_id_aa64dfr0_el1(). The BRBE system registers and instructions are currently trapped by the existing configuration of the fine-grained traps. As neither the registers nor the instructions are described in the sys_reg_descs[] table, emulate_sys_reg() will warn that these are unknown before injecting an UNDEFINED exception into the guest. Well-behaved guests shouldn't try to use the registers or instructions, but badly-behaved guests could use these, resulting in unnecessary warnings. To avoid those warnings, we should explicitly handle the BRBE registers and instructions as UNDEFINED. Address the above by having read_sanitised_id_aa64dfr0_el1() mask out the ID_AA64DFR0.BRBE field, and explicitly handling all of the BRBE system registers and instructions as UNDEFINED. Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oliver.upton@linux.dev> Cc: James Morse <james.morse@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: kvmarm@lists.linux.dev Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by:Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by:
Junhao He <hejunhao3@huawei.com>