[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1477993456.2236.7.camel@cvidal.org>
Date: Tue, 01 Nov 2016 10:44:16 +0100
From: Colin Vidal <colin@...dal.org>
To: kernel-hardening@...ts.openwall.com
Cc: keescook@...omium.org, arnd@...db.de, tglx@...utronix.de,
mingo@...hat.com, h.peter.anvin@...el.com, Elena Reshetova
<elena.reshetova@...el.com>, Hans Liljestrand <ishkamiel@...il.com>, David
Windsor <dwindsor@...il.com>
Subject: Re: [RFC v3 PATCH 01/13] Add architecture
independent hardened atomic base
Hi Elena,
> +As mentioned above, HARDENED_ATOMIC modifies the atomic_t API to provide its
> +protections. Following is a description of the functions that have been
> +modified.
> +
> +Benchmarks show that no measurable performance difference occurs when
> +HARDENED_ATOMIC is enabled.
> +
> +First, the type atomic_wrap_t needs to be defined for those kernel users who
> +want an atomic type that may be allowed to overflow/wrap (e.g. statistical
> +counters). Otherwise, the built-in protections (and associated costs) for
> +atomic_t would erroneously apply to these non-reference counter users of
> +atomic_t:
> +
> + * include/linux/types.h: define atomic_wrap_t and atomic64_wrap_t
> +
> +Next, we define the mechanism for reporting an overflow of a protected
> +atomic type:
> +
> + * kernel/panic.c: void hardened_atomic_overflow(struct pt_regs)
> +
<snip>
> diff --git a/include/linux/types.h b/include/linux/types.h
> index baf7183..b47a7f8 100644
> --- a/include/linux/types.h
> +++ b/include/linux/types.h
> @@ -175,10 +175,27 @@ typedef struct {
> int counter;
> } atomic_t;
>
> +#ifdef CONFIG_HARDENED_ATOMIC
> +typedef struct {
> + int counter;
> +} atomic_wrap_t;
> +#else
> +typedef atomic_t atomic_wrap_t;
> +#endif
> +
> #ifdef CONFIG_64BIT
> typedef struct {
> long counter;
> } atomic64_t;
> +
> +#ifdef CONFIG_HARDENED_ATOMIC
> +typedef struct {
> + long counter;
> +} atomic64_wrap_t;
> +#else
> +typedef atomic64_t atomic64_wrap_t;
> +#endif
> +
> #endif
>
I still think it would be a good idea to always distinct atomic*_wrap_t
and atomic_t. Otherwise, it is possible to mix those two types without
getting any error, if CONFIG_HARDENED_ATOMIC is disabled (no big deal
in that case, since there is no protection anyways, but it is quite
unclean...). What do you think?
Thanks
Colin
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
