Messages in this thread | | | From | Kees Cook <> | Date | Tue, 25 Jul 2017 12:25:57 -0700 | Subject | Re: [PATCH 2/2] lkdtm: Provide timing tests for atomic_t vs refcount_t |
| |
On Tue, Jul 25, 2017 at 11:33 AM, Kees Cook <keescook@chromium.org> wrote: > 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> > --- > drivers/misc/lkdtm.h | 2 ++ > drivers/misc/lkdtm_core.c | 2 ++ > drivers/misc/lkdtm_refcount.c | 44 +++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 48 insertions(+) > > diff --git a/drivers/misc/lkdtm.h b/drivers/misc/lkdtm.h > index 241d6f3a26dd..0b86947b31f5 100644 > --- a/drivers/misc/lkdtm.h > +++ b/drivers/misc/lkdtm.h > @@ -57,6 +57,8 @@ void lkdtm_REFCOUNT_DEC_SATURATED(void); > void lkdtm_REFCOUNT_ADD_SATURATED(void); > void lkdtm_REFCOUNT_DEC_AND_TEST_SATURATED(void); > void lkdtm_REFCOUNT_SUB_AND_TEST_SATURATED(void); > +void lkdtm_REFCOUNT_TIMING(void); > +void lkdtm_ATOMIC_TIMING(void); > > /* lkdtm_rodata.c */ > void lkdtm_rodata_do_nothing(void); > diff --git a/drivers/misc/lkdtm_core.c b/drivers/misc/lkdtm_core.c > index c3b045aec10e..5f949a05b307 100644 > --- a/drivers/misc/lkdtm_core.c > +++ b/drivers/misc/lkdtm_core.c > @@ -234,6 +234,8 @@ struct crashtype crashtypes[] = { > CRASHTYPE(REFCOUNT_ADD_SATURATED), > CRASHTYPE(REFCOUNT_DEC_AND_TEST_SATURATED), > CRASHTYPE(REFCOUNT_SUB_AND_TEST_SATURATED), > + CRASHTYPE(REFCOUNT_TIMING), > + CRASHTYPE(ATOMIC_TIMING), > CRASHTYPE(USERCOPY_HEAP_SIZE_TO), > CRASHTYPE(USERCOPY_HEAP_SIZE_FROM), > CRASHTYPE(USERCOPY_HEAP_FLAG_TO), > diff --git a/drivers/misc/lkdtm_refcount.c b/drivers/misc/lkdtm_refcount.c > index 234d39a07a99..8bad7baf0119 100644 > --- a/drivers/misc/lkdtm_refcount.c > +++ b/drivers/misc/lkdtm_refcount.c > @@ -306,3 +306,47 @@ void lkdtm_REFCOUNT_SUB_AND_TEST_SATURATED(void) > > check_saturated(&sat); > } > + > +/* Used to time the existing atomic_t when used for reference counting */ > +void lkdtm_ATOMIC_TIMING(void) > +{ > + unsigned int i; > + atomic_t count = ATOMIC_INIT(1); > + > + for (i = 0; i < INT_MAX; i++) > + atomic_inc(&count); > + > + for (i = INT_MAX; i >= 0; i--) > + if (atomic_dec_and_test(&count)) > + break; > + > + if (i != 0) > + pr_err("atomic timing: out of sync up/down cycle: %u\n", i); > + else > + pr_info("atomic timing: done\n"); > +} > + > +/* > + * This can be compared to ATOMIC_TIMING when implementing fast refcount > + * protections. Looking at the number of CPU cycles tells the real story > + * about performance. For example: > + * cd /sys/kernel/debug/provoke-crash > + * perf stat -B -- cat <(echo REFCOUNT_TIMING) > DIRECT > + */ > +void lkdtm_REFCOUNT_TIMING(void) > +{ > + unsigned int i; > + refcount_t count = REFCOUNT_INIT(1); > + > + for (i = 0; i < INT_MAX; i++)
Oops, bug snuck in at the last moment: this INT_MAX above and below (also in atomic_t above) should be INT_MAX - 1 since we start at 1, not zero.
> + refcount_inc(&count); > + > + for (i = INT_MAX; i >= 0; i--) > + if (refcount_dec_and_test(&count)) > + break; > + > + if (i != 0) > + pr_err("refcount: out of sync up/down cycle: %u\n", i); > + else > + pr_info("refcount timing: done\n"); > +} > -- > 2.7.4 >
-- Kees Cook Pixel Security
| |