linux-kernel - Re: [PATCH V3] arm64/cpuinfo: Define HWCAP name arrays per their actual bit definitions

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:   Tue, 8 Sep 2020 08:41:01 +0100
From:   Will Deacon <will@...nel.org>
To:     Anshuman Khandual <anshuman.khandual@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, catalin.marinas@....com,
        Mark Brown <broonie@...nel.org>,
        Dave Martin <Dave.Martin@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3] arm64/cpuinfo: Define HWCAP name arrays per their
 actual bit definitions

On Tue, Sep 08, 2020 at 10:43:12AM +0530, Anshuman Khandual wrote:
> 
> 
> On 09/07/2020 05:46 PM, Will Deacon wrote:
> > On Mon, Aug 17, 2020 at 05:34:23PM +0530, Anshuman Khandual wrote:
> >> HWCAP name arrays (hwcap_str, compat_hwcap_str, compat_hwcap2_str) that are
> >> scanned for /proc/cpuinfo are detached from their bit definitions making it
> >> vulnerable and difficult to correlate. It is also bit problematic because
> >> during /proc/cpuinfo dump these arrays get traversed sequentially assuming
> >> they reflect and match actual HWCAP bit sequence, to test various features
> >> for a given CPU. This redefines name arrays per their HWCAP bit definitions
> >> . It also warns after detecting any feature which is not expected on arm64.
> >>
> >> Cc: Catalin Marinas <catalin.marinas@....com>
> >> Cc: Will Deacon <will@...nel.org>
> >> Cc: Mark Brown <broonie@...nel.org>
> >> Cc: Dave Martin <Dave.Martin@....com>
> >> Cc: Ard Biesheuvel <ardb@...nel.org>
> >> Cc: Mark Rutland <mark.rutland@....com>
> >> Cc: Suzuki K Poulose <suzuki.poulose@....com>
> >> Cc: linux-arm-kernel@...ts.infradead.org
> >> Cc: linux-kernel@...r.kernel.org
> >> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
> >> ---
> >> This applies on 5.9-rc1
> >>
> >> Mark, since the patch has changed I have dropped your Acked-by: tag. Are you
> >> happy to give a new one ?
> >>
> >> Changes in V3:
> >>
> >> - Moved name arrays to (arch/arm64/kernel/cpuinfo.c) to prevent a build warning
> >> - Replaced string values with NULL for all compat features not possible on arm64
> >> - Changed compat_hwcap_str[] iteration on size as some NULL values are expected
> >> - Warn once after detecting any feature on arm64 that is not expected
> >>
> >> Changes in V2: (https://patchwork.kernel.org/patch/11533755/)
> >>
> >> - Defined COMPAT_KERNEL_HWCAP[2] and updated the name arrays per Mark
> >> - Updated the commit message as required
> >>
> >> Changes in V1: (https://patchwork.kernel.org/patch/11532945/)
> >>
> >>  arch/arm64/include/asm/hwcap.h |   9 +++
> >>  arch/arm64/kernel/cpuinfo.c    | 172 ++++++++++++++++++++++-------------------
> >>  2 files changed, 100 insertions(+), 81 deletions(-)
> > 
> > [...]
> > 
> >> +	[KERNEL_HWCAP_FP]		= "fp",
> >> +	[KERNEL_HWCAP_ASIMD]		= "asimd",
> >> +	[KERNEL_HWCAP_EVTSTRM]		= "evtstrm",
> >> +	[KERNEL_HWCAP_AES]		= "aes",
> > 
> > It would be nice if the cap and the string were generated by the same
> > macro, along the lines of:
> > 
> > #define KERNEL_HWCAP(c)	[KERNEL_HWCAP_##c] = #c,
> > 
> > Does making the constants mixed case break anything, or is it just really
> > churny to do?
> 
> Currently all existing HWCAP feature strings are lower case, above change
> will make them into upper case instead. I could not find a method to force
> convert #c into lower case constant strings in the macro definition. Would
> not changing the HWCAP string case here, break user interface ?

Yes, we can't change the user-visible strings, but what's wrong with
having e.g. KERNEL_HWCAP_fp instead of KERNEL_HWCAP_FP?

Will