diff options
author | Chris von Recklinghausen <crecklin@redhat.com> | 2018-07-03 22:43:08 +0300 |
---|---|---|
committer | Kees Cook <keescook@chromium.org> | 2018-07-04 18:04:52 +0300 |
commit | b5cb15d9372abc9adc4e844c0c1bf594ca6a7695 (patch) | |
tree | 191dc8291fd437d849716393d9ec7c7bcd2c346f /security/tomoyo/tomoyo.c | |
parent | 6aa56f44253a6dd802e45d8ab1b48847feaf063a (diff) | |
download | linux-b5cb15d9372abc9adc4e844c0c1bf594ca6a7695.tar.xz |
usercopy: Allow boot cmdline disabling of hardening
Enabling HARDENED_USERCOPY may cause measurable regressions in networking
performance: up to 8% under UDP flood.
I ran a small packet UDP flood using pktgen vs. a host b2b connected. On
the receiver side the UDP packets are processed by a simple user space
process that just reads and drops them:
https://github.com/netoptimizer/network-testing/blob/master/src/udp_sink.c
Not very useful from a functional PoV, but it helps to pin-point
bottlenecks in the networking stack.
When running a kernel with CONFIG_HARDENED_USERCOPY=y, I see a 5-8%
regression in the receive tput, compared to the same kernel without this
option enabled.
With CONFIG_HARDENED_USERCOPY=y, perf shows ~6% of CPU time spent
cumulatively in __check_object_size (~4%) and __virt_addr_valid (~2%).
The call-chain is:
__GI___libc_recvfrom
entry_SYSCALL_64_after_hwframe
do_syscall_64
__x64_sys_recvfrom
__sys_recvfrom
inet_recvmsg
udp_recvmsg
__check_object_size
udp_recvmsg() actually calls copy_to_iter() (inlined) and the latters
calls check_copy_size() (again, inlined).
A generic distro may want to enable HARDENED_USERCOPY in their default
kernel config, but at the same time, such distro may want to be able to
avoid the performance penalties in with the default configuration and
disable the stricter check on a per-boot basis.
This change adds a boot parameter that conditionally disables
HARDENED_USERCOPY via "hardened_usercopy=off".
Signed-off-by: Chris von Recklinghausen <crecklin@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Diffstat (limited to 'security/tomoyo/tomoyo.c')
0 files changed, 0 insertions, 0 deletions