| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
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>
|
|
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>
|
