linux-kernel - Re: [RFC PATCH 3/7] arm64: mm: use nGnRnE instead of nGnRE on Apple processors

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, 21 Jan 2021 11:44:23 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Will Deacon <will@...nel.org>
Cc:     Mohamed Mediouni <mohamed.mediouni@...amail.com>,
        linux-arm-kernel@...ts.infradead.org,
        Catalin Marinas <catalin.marinas@....com>,
        Mark Rutland <mark.rutland@....com>,
        Hector Martin <marcan@...can.st>, linux-kernel@...r.kernel.org,
        Stan Skowronek <stan@...ellium.com>
Subject: Re: [RFC PATCH 3/7] arm64: mm: use nGnRnE instead of nGnRE on Apple
 processors

On 2021-01-21 11:27, Will Deacon wrote:
> On Wed, Jan 20, 2021 at 02:27:13PM +0100, Mohamed Mediouni wrote:
>> Use nGnRnE instead of nGnRE on Apple SoCs to workaround a serious 
>> hardware quirk.
>> 
>> On Apple processors, writes using the nGnRE device memory type get 
>> dropped in flight,
>> getting to nowhere.
>> 
>> Signed-off-by: Stan Skowronek <stan@...ellium.com>
>> Signed-off-by: Mohamed Mediouni <mohamed.mediouni@...amail.com>
>> ---
>>  arch/arm64/mm/proc.S | 26 ++++++++++++++++++++++++++
>>  1 file changed, 26 insertions(+)
>> 
>> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
>> index 1f7ee8c8b7b8..06436916f137 100644
>> --- a/arch/arm64/mm/proc.S
>> +++ b/arch/arm64/mm/proc.S
>> @@ -51,6 +51,25 @@
>>  #define TCR_KASAN_HW_FLAGS 0
>>  #endif
>> 
>> +#ifdef CONFIG_ARCH_APPLE
>> +
>> +/*
>> + * Apple cores appear to black-hole writes done with nGnRE.
>> + * We settled on a work-around that uses MAIR vs changing every 
>> single user of
>> + * nGnRE across the arm64 code.
>> + */
>> +
>> +#define MAIR_EL1_SET_APPLE						\
>> +	(MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) |	\
>> +	 MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRE) |	\
>> +	 MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) |		\
>> +	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) |		\
>> +	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) |			\
>> +	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) |		\
>> +	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
>> +
>> +#endif
>> +
>>  /*
>>   * Default MAIR_EL1. MT_NORMAL_TAGGED is initially mapped as Normal 
>> memory and
>>   * changed during __cpu_setup to Normal Tagged if the system supports 
>> MTE.
>> @@ -432,6 +451,13 @@ SYM_FUNC_START(__cpu_setup)
>>  	 * Memory region attributes
>>  	 */
>>  	mov_q	x5, MAIR_EL1_SET
>> +#ifdef CONFIG_ARCH_APPLE
>> +	mrs	x0, MIDR_EL1
>> +	lsr	w0, w0, #24
>> +	mov_q	x1, MAIR_EL1_SET_APPLE
>> +	cmp	x0, #0x61			// 0x61 = Implementer: Apple
>> +	csel	x5, x1, x5, eq
> 
> Why does this need to be done so early? It would be a lot cleaner if we
> could detect this in a similar fashion to other errata and update the 
> MAIR
> appropriately. If that's not possible because of early IO mappings 
> (which
> ones?), then we could instead initialise to nGnRnE unconditionally, but
> relax it to nGnRE if we detect that we _don't_ have the erratum.

Would that imply another round-trip into the idmap, much like we do
when we switch to non-global mappings? Or do you expect that we can 
change
the MAIR with live mappings?

         M.
-- 
Jazz is not dead. It just smells funny...