[v2,0/4] Allow default HARDENED_USERCOPY to be set at compile time

Message

Mel Gorman Jan. 22, 2025, 5:19 p.m. UTC

Changelog since v1
o Menu section rename
o Make static branch usage similar to init_on_alloc
o Change ordering of menu options

Some hardening options like HARDENED_USERCOPY can be set at boot time
and have negligible cost when disabled. The default for options like
init_on_alloc= can be set at compile time but hardened usercopy is
enabled by default if built in. This incurs overhead when a kernel
wishes to provide optional hardening but the user does not necessarily
care.

Hardening is desirable in some environments but ideally they would be opt-in
by kernel command line as hardening is typically a deliberate decision
whereas the performance overhead is not always obvious to all users.
Patches 1 and 2 move HARDENED_USERCOPY to the Kconfig.hardening and
default it to disabled. Patch 3 moves the static branch check to a fast
path similar to init_on_*. Patch 4 moves FORTIFY_SOURCE to hardening only
because the option is related to hardening and happened to be declared
near HARDENED_USERCOPY.

Building HARDENED_USERCOPY but disabled at runtime has neligible effect
within the noise. Enabling the option by default generally incurs 2-10%
of overhead depending on the workload with some extreme outliers depending
on the exact CPU. While the benchmarks are somewhat synthetic, the overhead
IO-intensive and network-intensive is easily detectable but the root cause
may not be obvious (e.g. 2-14% overhead for netperf TCP_STREAM running
over localhost with different ranges depending on the CPU).

 .../admin-guide/kernel-parameters.txt         |  4 ++-
 include/linux/thread_info.h                   |  8 +++++
 mm/usercopy.c                                 | 14 ++++----
 security/Kconfig                              | 21 ------------
 security/Kconfig.hardening                    | 33 +++++++++++++++++++
 5 files changed, 52 insertions(+), 28 deletions(-)

Comments

Kees Cook Jan. 23, 2025, 1:02 a.m. UTC | #1

On Wed, Jan 22, 2025 at 05:19:21PM +0000, Mel Gorman wrote:
> on the exact CPU. While the benchmarks are somewhat synthetic, the overhead
> IO-intensive and network-intensive is easily detectable but the root cause
> may not be obvious (e.g. 2-14% overhead for netperf TCP_STREAM running
> over localhost with different ranges depending on the CPU).

I would be curious to see where this overhead is coming from. That seems
extraordinarily high, and makes me think there is something more we
should be fixing. :)

Mel Gorman Jan. 23, 2025, 11:49 a.m. UTC | #2

On Wed, Jan 22, 2025 at 05:02:29PM -0800, Kees Cook wrote:
> On Wed, Jan 22, 2025 at 05:19:21PM +0000, Mel Gorman wrote:
> > on the exact CPU. While the benchmarks are somewhat synthetic, the overhead
> > IO-intensive and network-intensive is easily detectable but the root cause
> > may not be obvious (e.g. 2-14% overhead for netperf TCP_STREAM running
> > over localhost with different ranges depending on the CPU).
> 
> I would be curious to see where this overhead is coming from. That seems
> extraordinarily high, and makes me think there is something more we
> should be fixing. :)
> 

Almost certainly yes, it could be anything really but the results are
consistent. It'll be somewhat tricky to narrow down given that it's
somewhat specific to the CPU. It was outside the scope of the series to
investigate. The primary aim was to provide the option to have hardened
usercopy available, but not surprising from a performance perspective,
via a single kernel binary.