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: <Z-4DqsRApwQi6Xju@gondor.apana.org.au>
Date: Thu, 3 Apr 2025 11:42:34 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Ard Biesheuvel <ardb@...nel.org>, linux-crypto@...r.kernel.org,
	linux-kernel@...r.kernel.org, x86@...nel.org,
	"Jason A. Donenfeld" <Jason@...c4.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Banning crypto in hardirq context (was: [PATCH v2 0/9] crypto: x86 -
 stop using the SIMD helper)

On Wed, Apr 02, 2025 at 08:20:08PM -0700, Eric Biggers wrote:
>
> Also, riscv has scalar AES instructions.  (They aren't used by the kernel yet,
> but they could be.  The CRC code already uses scalar carryless multiplication.)

It still doesn't mean that it's a good idea to use AES in a
hard IRQ handler, especially if the code is meant to be portable.

> Also, as I said already, x86 does support SIMD instructions in hardirq context
> in some cases.  Whether anyone actually uses that, I don't know, but it is
> explicitly supported.  Check out irq_fpu_usable().

This is more of an accident than some deliberate strategy of
supporting FPU usage in hard IRQs.  This test was initially
added for aesni:

commit 54b6a1bd5364aca95cd6ffae00f2b64c6511122c
Author: Ying Huang <huang.ying.caritas@...il.com>
Date:   Sun Jan 18 16:28:34 2009 +1100

    crypto: aes-ni - Add support to Intel AES-NI instructions for x86_64 platform

It was then improved by:

Author: Linus Torvalds <torvalds@...ux-foundation.org>
Date:   Mon Feb 13 13:56:14 2012 -0800

    i387: make irq_fpu_usable() tests more robust
    
    Some code - especially the crypto layer - wants to use the x86
    FP/MMX/AVX register set in what may be interrupt (typically softirq)
    context.

At no point was there any intention of using this in a hardirq
context.

Until such a time when you have a valid application for using
lib/crypto code in a hardirq context, I don't think we should
be supporting that at the expense of real users who are in
process/softirq context only.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ