Skip to content

Commit 7a60fe4

Browse files
Eric Biggersmimizohar
authored andcommitted
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>
1 parent 7caedbb commit 7a60fe4

2 files changed

Lines changed: 9 additions & 390 deletions

File tree

Documentation/admin-guide/kernel-parameters.txt

Lines changed: 0 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -2394,23 +2394,6 @@ Kernel parameters
23942394
[IMA] Define a custom template format.
23952395
Format: { "field1|...|fieldN" }
23962396

2397-
ima.ahash_minsize= [IMA] Minimum file size for asynchronous hash usage
2398-
Format: <min_file_size>
2399-
Set the minimal file size for using asynchronous hash.
2400-
If left unspecified, ahash usage is disabled.
2401-
2402-
ahash performance varies for different data sizes on
2403-
different crypto accelerators. This option can be used
2404-
to achieve the best performance for a particular HW.
2405-
2406-
ima.ahash_bufsize= [IMA] Asynchronous hash buffer size
2407-
Format: <bufsize>
2408-
Set hashing buffer size. Default: 4k.
2409-
2410-
ahash performance varies for different chunk sizes on
2411-
different crypto accelerators. This option can be used
2412-
to achieve best performance for particular HW.
2413-
24142397
ima= [IMA] Enable or disable IMA
24152398
Format: { "off" | "on" }
24162399
Default: "on"

0 commit comments

Comments
 (0)