linux-kernel - Re: [PATCH] arm64: Introduce ISAR6 CPU ID register

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]

Date:   Thu, 12 Dec 2019 15:22:13 +0000
From:   Suzuki Kuruppassery Poulose <suzuki.poulose@....com>
To:     Mark Rutland <mark.rutland@....com>,
        Anshuman Khandual <anshuman.khandual@....com>
Cc:     linux-arm-kernel@...ts.infradead.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
        James Morse <james.morse@....com>,
        linux-kernel@...r.kernel.org, kvmarm@...ts.cs.columbia.edu
Subject: Re: [PATCH] arm64: Introduce ISAR6 CPU ID register

On 12/12/2019 14:46, Mark Rutland wrote:
> On Thu, Dec 12, 2019 at 03:44:23PM +0530, Anshuman Khandual wrote:
>> +#define ID_ISAR6_JSCVT_SHIFT		0
>> +#define ID_ISAR6_DP_SHIFT		4
>> +#define ID_ISAR6_FHM_SHIFT		8
>> +#define ID_ISAR6_SB_SHIFT		12
>> +#define ID_ISAR6_SPECRES_SHIFT		16
>> +#define ID_ISAR6_BF16_SHIFT		20
>> +#define ID_ISAR6_I8MM_SHIFT		24
> 
>> @@ -399,6 +399,7 @@ static const struct __ftr_reg_entry {
>>   	ARM64_FTR_REG(SYS_ID_ISAR4_EL1, ftr_generic_32bits),
>>   	ARM64_FTR_REG(SYS_ID_ISAR5_EL1, ftr_id_isar5),
>>   	ARM64_FTR_REG(SYS_ID_MMFR4_EL1, ftr_id_mmfr4),
> 
>> +	ARM64_FTR_REG(SYS_ID_ISAR6_EL1, ftr_generic_32bits),
> 
> Using ftr_generic_32bits exposes the lowest-common-denominator for all
> 4-bit fields in the register, and I don't think that's the right thing
> to do here, because:
> 
> * We have no idea what ID_ISAR6 bits [31:28] may mean in future.
> 
> * AFAICT, the instructions described by ID_ISAR6.SPECRES (from the
>    ARMv8.0-PredInv extension) operate on the local PE and are not
>    broadcast. To make those work as a guest expects, the host will need
>    to do additional things (e.g. to preserve that illusion when a vCPU is
>    migrated from one pCPU to another and back).
> 
> Given that, think we should add an explicit ftr_id_isar6 which only
> exposes the fields that we're certain are safe to expose to a guest
> (i.e. without SPECRES).

Agree. Thanks for pointing this out. I recommended the usage of
generic_32bits table without actually looking at the feature
definitions.

Anshuman,

Sorry about this.

Cheers
Suzuki