linux-kernel - Re: [PATCH] arm64/mm: Fix __enable_mmu() for new TGRAN range values

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: <1f339512-34ac-9779-e534-bee6698b99aa@arm.com>
Date:   Sun, 7 Mar 2021 17:24:21 +0530
From:   Anshuman Khandual <anshuman.khandual@....com>
To:     Mark Rutland <mark.rutland@....com>
Cc:     linux-arm-kernel@...ts.infradead.org,
        James Morse <james.morse@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Ard Biesheuvel <ardb@...nel.org>, kvmarm@...ts.cs.columbia.edu,
        linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64/mm: Fix __enable_mmu() for new TGRAN range values



On 3/5/21 8:21 PM, Mark Rutland wrote:
> On Fri, Mar 05, 2021 at 08:06:09PM +0530, Anshuman Khandual wrote:
>> From: James Morse <james.morse@....com>
>>
>> As per ARM ARM DDI 0487G.a, when FEAT_LPA2 is implemented, ID_AA64MMFR0_EL1
>> might contain a range of values to describe supported translation granules
>> (4K and 16K pages sizes in particular) instead of just enabled or disabled
>> values. This changes __enable_mmu() function to handle complete acceptable
>> range of values (depending on whether the field is signed or unsigned) now
>> represented with ID_AA64MMFR0_TGRAN_SUPPORTED_[MIN..MAX] pair. While here,
>> also fix similar situations in EFI stub and KVM as well.
>>
>> Cc: Catalin Marinas <catalin.marinas@....com>
>> Cc: Will Deacon <will@...nel.org>
>> Cc: Marc Zyngier <maz@...nel.org>
>> Cc: James Morse <james.morse@....com>
>> Cc: Suzuki K Poulose <suzuki.poulose@....com>
>> Cc: Ard Biesheuvel <ardb@...nel.org>
>> Cc: Mark Rutland <mark.rutland@....com>
>> Cc: linux-arm-kernel@...ts.infradead.org
>> Cc: kvmarm@...ts.cs.columbia.edu
>> Cc: linux-efi@...r.kernel.org
>> Cc: linux-kernel@...r.kernel.org
>> Signed-off-by: James Morse <james.morse@....com>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
>> ---
>>  arch/arm64/include/asm/sysreg.h           | 20 ++++++++++++++------
>>  arch/arm64/kernel/head.S                  |  6 ++++--
>>  arch/arm64/kvm/reset.c                    | 23 ++++++++++++-----------
>>  drivers/firmware/efi/libstub/arm64-stub.c |  2 +-
>>  4 files changed, 31 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
>> index dfd4edb..d4a5fca9 100644
>> --- a/arch/arm64/include/asm/sysreg.h
>> +++ b/arch/arm64/include/asm/sysreg.h
>> @@ -796,6 +796,11 @@
>>  #define ID_AA64MMFR0_PARANGE_48		0x5
>>  #define ID_AA64MMFR0_PARANGE_52		0x6
>>  
>> +#define ID_AA64MMFR0_TGRAN_2_SUPPORTED_DEFAULT	0x0
>> +#define ID_AA64MMFR0_TGRAN_2_SUPPORTED_NONE	0x1
>> +#define ID_AA64MMFR0_TGRAN_2_SUPPORTED_MIN	0x2
>> +#define ID_AA64MMFR0_TGRAN_2_SUPPORTED_MAX	0x7
>
> The TGRAN2 fields doesn't quite follow the usual ID scheme rules, so how
> do we deteremine the max value? Does the ARM ARM say anything in
> particular about them, like we do for some of the PMU ID fields?

Did not find anything in ARM ARM, regarding what scheme TGRAN2 fields
actually follow. I had arrived at more restrictive 0x7 value, like the
usual signed fields as the TGRAN4 fields definitely do not follow the
unsigned ID scheme. Would restricting max value to 0x3 (i.e LPA2) be a
better option instead ?

> 
> Otherwise, this patch looks correct to me.
> 
> Thanks,
> Mark.
>