lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3ba53c71-114a-4ac9-b590-7332e97b6fc4@arm.com>
Date:   Mon, 11 Dec 2023 12:04:05 +0530
From:   Anshuman Khandual <anshuman.khandual@....com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        will@...nel.org, catalin.marinas@....com, mark.rutland@....com,
        Mark Brown <broonie@...nel.org>,
        James Clark <james.clark@....com>,
        Rob Herring <robh@...nel.org>,
        Suzuki Poulose <suzuki.poulose@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        linux-perf-users@...r.kernel.org,
        Oliver Upton <oliver.upton@...ux.dev>,
        James Morse <james.morse@....com>, kvmarm@...ts.linux.dev
Subject: Re: [PATCH V15 2/8] KVM: arm64: Prevent guest accesses into BRBE
 system registers/instructions



On 12/4/23 13:52, Marc Zyngier wrote:
> On Fri, 01 Dec 2023 05:39:00 +0000,
> Anshuman Khandual <anshuman.khandual@....com> wrote:
>> Currently BRBE feature is not supported in a guest environment. This hides
>> BRBE feature availability via masking ID_AA64DFR0_EL1.BRBE field. This also
>> blocks guest accesses into BRBE system registers and instructions as if the
>> underlying hardware never implemented FEAT_BRBE feature.
>>
>> Cc: Marc Zyngier <maz@...nel.org>
>> Cc: Oliver Upton <oliver.upton@...ux.dev>
>> Cc: James Morse <james.morse@....com>
>> Cc: Suzuki K Poulose <suzuki.poulose@....com>
>> Cc: Catalin Marinas <catalin.marinas@....com>
>> Cc: Will Deacon <will@...nel.org>
>> Cc: kvmarm@...ts.linux.dev
>> Cc: linux-arm-kernel@...ts.infradead.org
>> Cc: linux-kernel@...r.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
>> ---
>>  arch/arm64/kvm/sys_regs.c | 130 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 130 insertions(+)
>>
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index 4735e1b37fb3..42701065b3cd 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -1583,6 +1583,9 @@ static u64 read_sanitised_id_aa64dfr0_el1(struct kvm_vcpu *vcpu,
>>  	/* Hide SPE from guests */
>>  	val &= ~ID_AA64DFR0_EL1_PMSVer_MASK;
>>  
>> +	/* Hide BRBE from guests */
>> +	val &= ~ID_AA64DFR0_EL1_BRBE_MASK;
>> +
>>  	return val;
>>  }
>>  
>> @@ -2042,6 +2045,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>  	{ SYS_DESC(SYS_DC_CISW), access_dcsw },
>>  	{ SYS_DESC(SYS_DC_CIGSW), access_dcgsw },
>>  	{ SYS_DESC(SYS_DC_CIGDSW), access_dcgsw },
>> +	{ SYS_DESC(OP_BRB_IALL), undef_access },
>> +	{ SYS_DESC(OP_BRB_INJ), undef_access },
>>  
>>  	DBG_BCR_BVR_WCR_WVR_EL1(0),
>>  	DBG_BCR_BVR_WCR_WVR_EL1(1),
>> @@ -2072,6 +2077,131 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>>  	{ SYS_DESC(SYS_DBGCLAIMCLR_EL1), trap_raz_wi },
>>  	{ SYS_DESC(SYS_DBGAUTHSTATUS_EL1), trap_dbgauthstatus_el1 },
>>  
>> +	/*
>> +	 * BRBE branch record sysreg address space is interleaved between
>> +	 * corresponding BRBINF<N>_EL1, BRBSRC<N>_EL1, and BRBTGT<N>_EL1.
>> +	 */
>> +	{ SYS_DESC(SYS_BRBINF0_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBSRC0_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBTGT0_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBINF16_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBSRC16_EL1), undef_access },
>> +	{ SYS_DESC(SYS_BRBTGT16_EL1), undef_access },
> Surely we can do better than this wall of text. Please look at what we
> do for the debug registers, and adopt a similar pattern. This should
> result in one line per group of 3 registers.

Sure, will these replace via the following macro.

+#define BRB_INF_SRC_TGT_EL1(n)                                 \
+       { SYS_DESC(SYS_BRBINF##n##_EL1), undef_access },        \
+       { SYS_DESC(SYS_BRBSRC##n##_EL1), undef_access },        \
+       { SYS_DESC(SYS_BRBTGT##n##_EL1), undef_access }         \
....
+       BRB_INF_SRC_TGT_EL1(0),
+       BRB_INF_SRC_TGT_EL1(16),
+       BRB_INF_SRC_TGT_EL1(1),
+       BRB_INF_SRC_TGT_EL1(17),
+       BRB_INF_SRC_TGT_EL1(2),
+       BRB_INF_SRC_TGT_EL1(18),
+       BRB_INF_SRC_TGT_EL1(3),
+       BRB_INF_SRC_TGT_EL1(19),
....

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ