linux-kernel - Re: [PATCH] [v1] arch: arm: configs: gxp

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: <CAK8P3a3z8uT+0p55N_it3Mg-J08dn31S4rCLoXdK4eheyOR0Eg@mail.gmail.com>
Date:   Wed, 23 Mar 2022 00:04:45 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     "Verdun, Jean-Marie" <verdun@....com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        "Hawkins, Nick" <nick.hawkins@....com>,
        Russell King <linux@...linux.org.uk>,
        Joel Stanley <joel@....id.au>,
        Andrew Jeffery <andrew@...id.au>,
        Olof Johansson <olof@...om.net>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [v1] arch: arm: configs: gxp_defconfig

On Tue, Mar 22, 2022 at 11:41 PM Verdun, Jean-Marie <verdun@....com> wrote:

> I spent additional time to analyze the issue

Thank you for putting the work into the analysis!

> Would you accept a patch which is switching PERF_EVENTS=y to
> PERF_EVENTS=m into multi_v7_defconfig ?

Unfortunately that is not possible at the moment, as this is a 'bool'
option rather than
a 'tristate'. I don't know if it might be possible to change that, but
this is probably
done for a good reason.

> Then we could add our GXP definition into it like other chips are. This could also
> help other chip vendors affected by the same bug. I am pretty sure we are not the
> only one. Reducing defconfig file and relying on general purpose one per architecture
> revision make totally sense to me.

I think it should be possible to detect this erratum at runtime, especially now
that we understand what the hardware issue is.

We should probably add a CONFIG_ARM_ERRATA_764319 Kconfig
option that controls whether a workaround is enabled or not. One
way that I think this can be handled is to have a custom inline asm
for the trapping register CP14 accesses, using a __ex_table fixup,
similar to what we do for trapping user space memory access.

Another option would be to detect affected systems by the CPU
revision register or from some DT properties.

       Arnd