Re: [PATCH] audit: always enable syscall auditing when supported and audit is enabled
From: Sverdlin, Alexander (Nokia - DE/Ulm)
Date: Mon Jan 28 2019 - 10:38:20 EST
Hello Paul,
On 28/01/2019 15:52, Paul Moore wrote:
>>>>> time also enables syscall auditing; this patch simplifies the Kconfig
>>>>> menus by removing the option to disable syscall auditing when audit
>>>>> is selected and the target arch supports it.
>>>>>
>>>>> Signed-off-by: Paul Moore <pmoore@xxxxxxxxxx>
>>>> this patch is responsible for massive performance degradation for those
>>>> who used only CONFIG_SECURITY_APPARMOR.
>>>>
>>>> And the numbers are, take the following test for instance:
>>>>
>>>> dd if=/dev/zero of=/dev/null count=2M
>>>>
>>>> ARM64: 500MB/s -> 350MB/s
>>>> ARM: 400MB/s -> 300MB/s
>>> Hi there.
>>>
>>> Out of curiosity, what kernel/distribution are you running, or is this
>>> a custom kernel compile? Can you also share the output of 'auditctl
>> This test was carried out with Linux 4.9. Custom built.
> I suspected that was the case, thanks.
>
>>> -l' from your system? The general approach taken by everyone to
>>> turn-off the per-syscall audit overhead is to add the "-a never,task"
>>> rule to their audit configuration:
>>>
>>> # auditctl -a never,task
>>>
>>> If you are using Fedora/CentOS/RHEL, or a similarly configured system,
>> This is an embedded distribution. We are not using auditctl or any other
>> audit-related user-space packages.
>>
>>> you can find this configuration in the /etc/audit/audit.rules file (be
>>> warned, that file is automatically generated based on
>>> /etc/audit/rules.d).
>> I suppose in this case rule list must be empty. Is there a way to check
>> this without extra user-space packages?
> Yes, unless you are loading rules through some other method I would
> expect that your audit rule list is empty.
>
> I'm not aware of any other tools besides auditctl to load audit rules
> into the kernel, although I haven't ever had a need for another tool
> so I haven't looked very hard. If you didn't want to bring auditctl
> into your distribution, I expect it would be a rather trivial task to
> create a small tool to load a single "-a never,task" into the kernel.
I've done a quick test on my x86_64 PC and got the following results:
1. empty rules list:
perf record dd if=/dev/zero of=/dev/null count=2M
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.69685 s, 633 MB/s
perf report:
# Overhead Command Shared Object Symbol
# ........ ....... ................. ..................................
#
14.26% dd [kernel.kallsyms] [k] entry_SYSCALL_64
11.33% dd [kernel.kallsyms] [k] __clear_user
5.00% dd [kernel.kallsyms] [k] fsnotify
4.92% dd libc-2.28.so [.] read
4.80% dd [kernel.kallsyms] [k] __audit_syscall_exit
4.60% dd [kernel.kallsyms] [k] syscall_return_via_sysret
4.24% dd libc-2.28.so [.] __GI___libc_write
3.84% dd [kernel.kallsyms] [k] __indirect_thunk_start
3.82% dd libc-2.28.so [.] __memcpy_ssse3_back
3.04% dd [kernel.kallsyms] [k] entry_SYSCALL_64_after_hwframe
2.98% dd [kernel.kallsyms] [k] __fget_light
2.97% dd [kernel.kallsyms] [k] do_syscall_64
2.33% dd [kernel.kallsyms] [k] vfs_write
2.32% dd [kernel.kallsyms] [k] __audit_syscall_entry
2.31% dd [kernel.kallsyms] [k] iov_iter_zero
2.22% dd [kernel.kallsyms] [k] syscall_trace_enter
1.89% dd [kernel.kallsyms] [k] syscall_slow_exit_work
1.56% dd [kernel.kallsyms] [k] __fsnotify_parent
1.52% dd [kernel.kallsyms] [k] __x64_sys_write
1.42% dd [kernel.kallsyms] [k] __vfs_read
1.34% dd [kernel.kallsyms] [k] __x64_sys_read
1.30% dd [kernel.kallsyms] [k] vfs_read
1.16% dd [kernel.kallsyms] [k] ksys_write
1.05% dd [kernel.kallsyms] [k] security_file_permission
2. auditctl -a never,task
perf record dd if=/dev/zero of=/dev/null count=2M
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.29384 s, 830 MB/s
perf report:
# Overhead Command Shared Object Symbol
# ........ ....... ................. ...................................
#
16.90% dd [kernel.kallsyms] [k] entry_SYSCALL_64
14.24% dd [kernel.kallsyms] [k] __clear_user
6.00% dd [kernel.kallsyms] [k] fsnotify
5.35% dd [kernel.kallsyms] [k] syscall_return_via_sysret
5.26% dd [kernel.kallsyms] [k] __indirect_thunk_start
4.85% dd libc-2.28.so [.] read
4.81% dd libc-2.28.so [.] __GI___libc_write
4.09% dd libc-2.28.so [.] __memcpy_ssse3_back
3.92% dd [kernel.kallsyms] [k] __fget_light
3.43% dd [kernel.kallsyms] [k] entry_SYSCALL_64_after_hwframe
3.07% dd [kernel.kallsyms] [k] iov_iter_zero
2.93% dd [kernel.kallsyms] [k] do_syscall_64
2.45% dd [kernel.kallsyms] [k] vfs_write
2.07% dd [kernel.kallsyms] [k] __vfs_read
2.02% dd [kernel.kallsyms] [k] __fsnotify_parent
1.42% dd [kernel.kallsyms] [k] vfs_read
1.34% dd [kernel.kallsyms] [k] ksys_read
1.18% dd [kernel.kallsyms] [k] ksys_write
1.18% dd [kernel.kallsyms] [k] read_iter_zero
1.10% dd [kernel.kallsyms] [k] __vfs_write
Which brings me to an idea, that the subject patch should have been accompanied
by a default "never,task" rule inside the kernel, otherwise you require an
extra user-space package (audit) just to bring Linux 4.5+ to 4.4 performance
levels.
--
Best regards,
Alexander Sverdlin.