ima: remove buggy support for asynchronous hashes

IMA computes hashes using the crypto_shash or crypto_ahash API.  The
latter is used only when ima.ahash_minsize is set on the command line,
and its purpose is ostensibly to make the hash computation faster.

However, going off the CPU to a crypto engine and back again is actually
quite slow, especially compared with the acceleration that is built into
modern CPUs and the kernel now enables by default for most algorithms.
Typical performance results for SHA-256 on a modern platform can be
found at https://lore.kernel.org/linux-crypto/20250615184638.GA1480@sol/

Partly for this reason, several other kernel subsystems have already
dropped support for the crypto_ahash API.

The other problem with crypto_ahash is that bugs are also common, not
just in the underlying drivers, but also in the code using it, since it
is very difficult to use correctly.  Just from a quick review, here are
some of the bugs I noticed in IMA's ahash code:

- [Use after free] ima_alloc_atfm() isn't thread-safe and can trigger a
  use-after-free if multiple threads try to initialize the global
  ima_ahash_tfm at the same time.

- [Deadlock] If only one buffer is allocated and there is an error
  reading from the file, then ahash_wait() is executed twice, causing a
  deadlock in wait_for_completion().

- [Crash or incorrect hash computed] calc_buffer_ahash_atfm() is
  sometimes passed stack buffers which can be vmalloc addresses, but it
  puts them in a scatterlist assuming they are linear addresses.  This
  causes the hashing to be done on the wrong physical address.

- [Truncation to 32-bit length] ima_alloc_pages() incorrectly assumes an
  loff_t value fits in an unsigned long.  calc_buffer_ahash_atfm()
  incorrectly assumes that a loff_t value fits in an unsigned int.

So, not exactly a great track record so far, even disregarding driver
bugs which are an even larger problem.  Fortunately, in practice it's
unlikely that many users are actually setting the ima.ahash_minsize
kernel command-line parameter which enables this code.  However, given
that this code is almost certainly no longer useful (if it ever was),
let's just remove it instead of attempting to fix all these issues.

Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Acked-by: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>

0 files changed, 0 insertions, 0 deletions