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, 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

Powered by blists - more mailing lists