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: Fri, 1 Dec 2017 18:24:10 +0000 From: Dave Martin <Dave.Martin@....com> To: Russell King - ARM Linux <linux@...linux.org.uk>, Sebastian Andrzej Siewior <bigeasy@...utronix.de> Cc: Mark Rutland <mark.rutland@....com>, linux-rt-users@...r.kernel.org, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Peter Zijlstra <peterz@...radead.org>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>, linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>, tglx@...utronix.de, linux-arm-kernel@...ts.infradead.org Subject: Re: [PATCH RT] arm*: disable NEON in kernel mode On Fri, Dec 01, 2017 at 06:08:28PM +0000, Russell King - ARM Linux wrote: > On Fri, Dec 01, 2017 at 05:58:45PM +0000, Dave Martin wrote: > > +1, at least for arm64. I don't see a really compelling reason for > > holding kernel-mode NEON around memory management now that we have a > > strict save-once-restore-lazily model. > > > > This may not work so well for arm though -- I haven't looked at that > > code for a while. > > > > > > If there is memory manamement in any core loop, you already lost > > the performance battle, and an extra > > kernel_neon_end()+kernel_neon_begin() may not be that catastrophic. > > Remember that we don't permit context switches while kernel neon is > in use on ARM - if there's any possibility of scheduling to occur, > the get_cpu() in kernel_neon_begin() should trigger a schedule-while- > atomic warning. Agreed, and an arm64 the same is true. (Actually softirq is disabled too, for tortuous reasons involving SVE.) On 2017-12-01 11:43:32 [+0100], To linux-rt-users@...r.kernel.org wrote: > NEON in kernel mode is used by the crypto algorithms and raid6 code. > While the raid6 code looks okay, the crypto algorithms do not: NEON > is enabled on first invocation and may allocate/free/map memory before > the NEON mode is disabled again. > This needs to be changed until it can be enabled. > On ARM NEON in kernel mode can be simply disabled. on ARM64 it needs to > stay on due to possible EFI callbacks so here I disable each algorithm. [...] > diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig > index 70c517aa4501..2a5f05b5a19a 100644 > --- a/arch/arm64/crypto/Kconfig > +++ b/arch/arm64/crypto/Kconfig > @@ -19,19 +19,19 @@ config CRYPTO_SHA512_ARM64 > > config CRYPTO_SHA1_ARM64_CE > tristate "SHA-1 digest algorithm (ARMv8 Crypto Extensions)" > - depends on KERNEL_MODE_NEON > + depends on KERNEL_MODE_NEON && !PREEMPT_RT_BASE > select CRYPTO_HASH > select CRYPTO_SHA1 Sebastian, can you piont to where sha1 (say) hits this issue? I wonder whether this is really a sign that some refactoring is needed. Cheers ---Dave
Powered by blists - more mailing lists