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] [day] [month] [year] [list]
Date:   Tue, 8 Mar 2022 19:09:14 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Arnd Bergmann <arnd@...db.de>, Marc Zyngier <maz@...nel.org>,
        Rongwei Wang <rongwei.wang@...ux.alibaba.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, joey.gouly@....com,
        Mark Rutland <mark.rutland@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] arm64: improve display about CPU architecture in
 cpuinfo

On 2022-03-08 17:57, Russell King (Oracle) wrote:
> On Mon, Mar 07, 2022 at 08:05:06PM +0000, Robin Murphy wrote:
>> On 2022-03-07 19:30, Arnd Bergmann wrote:
>>> On Mon, Mar 7, 2022 at 5:48 PM Robin Murphy <robin.murphy@....com> wrote:
>>>
>>>> And arguably it's not even too late, because 10 years ago this *did* say
>>>> "AArch64". I don't remember all the exact details behind commit
>>>> 44b82b7700d0 ("arm64: Fix up /proc/cpuinfo") - this just tickled enough
>>>> of a memory to go and look up the git history - but I don't think we
>>>> changed any of those fields without a real reason.
>>>>
>>>
>>> The patch description does state that this was done for compatibility with
>>> 32-bit architectures, which does make some sense. I suppose for similar
>>> reasons, the arch/arm/ version of /proc/cpuinfo is now stuck at
>>> 'CPU architecture: 7', even for ARMv8 or higher in aarch32 mode.
>>>
>>> The part that I find more annoying is how we leave out the one bit
>>> of information that people are generally looking for in /proc/cpuinfo:
>>> the name of the processor. Even though we already know the
>>> exact processor type in order to handle the CPU errata, this is
>>> always "model name\t: ARMv7 Processor rev %d (v7l)" on 32-bit,
>>> and "model name\t: ARMv8 Processor rev %d (%s)" on 64-bit,
>>> with the revision being the least important bit of information here...
>>
>> Eh, it's hardly impossible to recompose a MIDR value from the implementer,
>> part, variant and revision fields if one actually needs to. Maybe we could
>> null-terminate the raw MIDR value and print it as a string of
>> largely-unprintable characters in the "model name" field... I guess that
>> might satisfy the crowd who want parity* with x86 CPUID, at least :)
> 
> Actually, it is impossible to do it reliably. I won't expand on this,
> except what I said in my other reply - there are cases where the MIDR
> value is not unique.

Sorry, I was assuming the given context of CPUs which report as v7 or 
v8, where one can safely and unambiguously infer that the missing 
original MIDR.Architecture value was 0xf. No implication was intended 
that it was possible for everything in general.

Robin.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ