linux-kernel - Re: [PATCH v2 1/7] arm64: capabilities: Merge entries for ARM64_WORKAROUND_CLEAN

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:   Wed, 5 Dec 2018 15:02:52 +0000
From:   Will Deacon <will.deacon@....com>
To:     Suzuki K Poulose <suzuki.poulose@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        catalin.marinas@....com, dave.martin@....com, mark.rutland@....com,
        vladimir.murzin@....com, Andre Przywara <andre.przywara@....com>
Subject: Re: [PATCH v2 1/7] arm64: capabilities: Merge entries for
 ARM64_WORKAROUND_CLEAN_CACHE

On Fri, Nov 30, 2018 at 05:18:00PM +0000, Suzuki K Poulose wrote:
> We have two entries for ARM64_WORKAROUND_CLEAN_CACHE capability :
> 
> 1) ARM Errata 826319, 827319, 824069, 819472 on A53 r0p[012]
> 2) ARM Errata 819472 on A53 r0p[01]
> 
> Both have the same work around. Merge these entries to avoid
> duplicate entries for a single capability. Add a new Kconfig
> entry to control the "capability" entry to make it easier
> to handle combinations of the CONFIGs.
> 
> Cc: Will Deacon <will.deacon@....com>
> Cc: Andre Przywara <andre.przywara@....com>
> Cc: Mark Rutland <mark.rutland@....com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
> ---
>  arch/arm64/Kconfig               |  7 +++++++
>  arch/arm64/include/asm/cputype.h |  1 +
>  arch/arm64/kernel/cpu_errata.c   | 28 ++++++++++++++++------------
>  3 files changed, 24 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 787d785..ad69e15 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -313,9 +313,13 @@ menu "Kernel Features"
>  
>  menu "ARM errata workarounds via the alternatives framework"
>  
> +config ARM64_WORKAROUND_CLEAN_CACHE
> +	def_bool n
> +
>  config ARM64_ERRATUM_826319
>  	bool "Cortex-A53: 826319: System might deadlock if a write cannot complete until read data is accepted"
>  	default y
> +	select ARM64_WORKAROUND_CLEAN_CACHE
>  	help
>  	  This option adds an alternative code sequence to work around ARM
>  	  erratum 826319 on Cortex-A53 parts up to r0p2 with an AMBA 4 ACE or
> @@ -337,6 +341,7 @@ config ARM64_ERRATUM_826319
>  config ARM64_ERRATUM_827319
>  	bool "Cortex-A53: 827319: Data cache clean instructions might cause overlapping transactions to the interconnect"
>  	default y
> +	select ARM64_WORKAROUND_CLEAN_CACHE
>  	help
>  	  This option adds an alternative code sequence to work around ARM
>  	  erratum 827319 on Cortex-A53 parts up to r0p2 with an AMBA 5 CHI
> @@ -358,6 +363,7 @@ config ARM64_ERRATUM_827319
>  config ARM64_ERRATUM_824069
>  	bool "Cortex-A53: 824069: Cache line might not be marked as clean after a CleanShared snoop"
>  	default y
> +	select ARM64_WORKAROUND_CLEAN_CACHE
>  	help
>  	  This option adds an alternative code sequence to work around ARM
>  	  erratum 824069 on Cortex-A53 parts up to r0p2 when it is connected
> @@ -380,6 +386,7 @@ config ARM64_ERRATUM_824069
>  config ARM64_ERRATUM_819472
>  	bool "Cortex-A53: 819472: Store exclusive instructions might cause data corruption"
>  	default y
> +	select ARM64_WORKAROUND_CLEAN_CACHE
>  	help
>  	  This option adds an alternative code sequence to work around ARM
>  	  erratum 819472 on Cortex-A53 parts up to r0p1 with an L2 cache
> diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
> index 12f93e4d..2e26375 100644
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@ -151,6 +151,7 @@ struct midr_range {
>  		.rv_max = MIDR_CPU_VAR_REV(v_max, r_max),	\
>  	}
>  
> +#define MIDR_REV_RANGE(m, v, r_min, r_max) MIDR_RANGE(m, v, r_min, v, r_max)

What's the point of this macro?

Will