On Mon, Sep 11, 2023 at 03:38:20PM +0200, Greg Kroah-Hartman wrote:
> 6.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Eric Snowberg <eric.snowberg@xxxxxxxxxx>
>
> [ Upstream commit 18b44bc5a67275641fb26f2c54ba7eef80ac5950 ]
>
> Commit db1d1e8b9867 ("IMA: use vfs_getattr_nosec to get the i_version")
> partially closed an IMA integrity issue when directly modifying a file
> on the lower filesystem. If the overlay file is first opened by a user
> and later the lower backing file is modified by root, but the extended
> attribute is NOT updated, the signature validation succeeds with the old
> original signature.
>
> Update the super_block s_iflags to SB_I_IMA_UNVERIFIABLE_SIGNATURE to
> force signature reevaluation on every file access until a fine grained
> solution can be found.
>
Sorry for replying to the 6.4-stable patch, I couldn't find the original
patch in the mailing list.
We recently upgraded from 6.4.4 to 6.5.3. We have the integrity LSM
enabled, and are using overlayfs. When we try and execute a binary from
the overlayfs filesystem, the integrity LSM hashes the binary and all
its shared objects every single invocation. This causes a serious
performance regression when invoking clang thousands of times while
building a package. We bisected the culprit down to this patch.
Here are some numbers:
With this patch + overlayfs:
$ time /usr/bin/clang-17 --version > /dev/null
real 0m0.628s
user 0m0.004s
sys 0m0.624s
$ time /usr/bin/clang-17 --version > /dev/null
real 0m0.597s
user 0m0.004s
sys 0m0.593s
With this patch - overlayfs:
$ truncate -s 1G foo.bin
$ mkfs.ext4 foo.bin
$ mount foo.bin /foo
$ cp /usr/bin/clang-17 /foo
$ time /foo/clang-17 --version > /dev/null
real 0m0.040s
user 0m0.009s
sys 0m0.031s
$ time /foo/clang-17 --version > /dev/null
real 0m0.036s
user 0m0.000s
sys 0m0.037s
Without this path + overlayfs:
$ time /usr/bin/clang-17 --version > /dev/null
real 0m0.017s
user 0m0.007s
sys 0m0.011s
$ time /usr/bin/clang-17 --version > /dev/null
real 0m0.018s
user 0m0.000s
sys 0m0.018s
i.e., we go from ~30ms / invocation to 600ms / invocation. Building
glibc used to take about 3 minutes, but now its taking about 20 minutes.
Our clang binary is about 100 MiB in size.
Using `perf` the following sticks out:
$ perf record -g time /usr/bin/clang-17 --version
--92.03%--elf_map
vm_mmap_pgoff
ima_file_mmap
process_measurement
ima_collect_measurement
|
--91.95%--ima_calc_file_hash
ima_calc_file_hash_tfm
|
|--82.85%--_sha256_update
| |
| --82.47%--lib_sha256_base_do_update.isra.0
| |
| --82.39%--sha256_transform_rorx
|
--9.10%--integrity_kernel_read
The audit.log is also logging every clang invocation as well.
Was such a large performance regression expected? Can the commit be
reverted until the more fine grained solution mentioned in the commit
message be implemented?
Thanks,
Raul
> Signed-off-by: Eric Snowberg <eric.snowberg@xxxxxxxxxx>
> Signed-off-by: Mimi Zohar <zohar@xxxxxxxxxxxxx>
> Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
> ---
> fs/overlayfs/super.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
> index ae1058fbfb5b2..8c60da7b4afd8 100644
> --- a/fs/overlayfs/super.c
> +++ b/fs/overlayfs/super.c
> @@ -2052,7 +2052,7 @@ static int ovl_fill_super(struct super_block *sb, void *data, int silent)
> ovl_trusted_xattr_handlers;
> sb->s_fs_info = ofs;
> sb->s_flags |= SB_POSIXACL;
> - sb->s_iflags |= SB_I_SKIP_SYNC;
> + sb->s_iflags |= SB_I_SKIP_SYNC | SB_I_IMA_UNVERIFIABLE_SIGNATURE;
>
> err = -ENOMEM;
> root_dentry = ovl_get_root(sb, upperpath.dentry, oe);
> --
> 2.40.1
>
>
>
