Commit Graph

3 Commits

Author SHA1 Message Date
Colin Ian King
917c8c2570 lkdtm: fix spelling mistake: "incremeted" -> "incremented"
Trivial fix to spelling mistake in pr_info message

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-28 17:47:11 +02:00
Kees Cook
c7fea48876 lkdtm: Provide timing tests for atomic_t vs refcount_t
While not a crash test, this does provide two tight atomic_t and
refcount_t loops for performance comparisons:

	cd /sys/kernel/debug/provoke-crash
	perf stat -B -- cat <(echo ATOMIC_TIMING) > DIRECT
	perf stat -B -- cat <(echo REFCOUNT_TIMING) > DIRECT

Looking a CPU cycles is the best way to example the fast-path (rather
than instruction counts, since conditional jumps will be executed but
will be negligible due to branch-prediction).

Signed-off-by: Kees Cook <keescook@chromium.org>
2017-07-26 14:38:04 -07:00
Kees Cook
95925c99b9 lkdtm: Provide more complete coverage for REFCOUNT tests
The existing REFCOUNT_* LKDTM tests were designed only for testing a narrow
portion of CONFIG_REFCOUNT_FULL. This moves the tests to their own file and
expands their testing to poke each boundary condition.

Since the protections (CONFIG_REFCOUNT_FULL and x86-fast) use different
saturation values and reach-zero behavior, those have to be build-time
set so the tests can actually validate things are happening at the
right places.

Notably, the x86-fast protection will fail REFCOUNT_INC_ZERO and
REFCOUNT_ADD_ZERO since those conditions are not checked (only overflow
is critical to protecting refcount_t). CONFIG_REFCOUNT_FULL will warn for
each REFCOUNT_*_NEGATIVE test since it provides zero-pinning behaviors
(which allows it to pass REFCOUNT_INC_ZERO and REFCOUNT_ADD_ZERO).

Signed-off-by: Kees Cook <keescook@chromium.org>
2017-07-26 14:38:03 -07:00