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