Re: [PATCH] audit: always enable syscall auditing when supported and audit is enabled

[Sverdlin, Alexander (Nokia - DE/Ulm)]

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.