[kernel-hardening] Re: [RFC v4 PATCH 12/13] x86: implementation for HARDENED_ATOMIC

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Nov 10, 2016 at 01:32:50PM -0800, Kees Cook wrote:
> > Also, I hate how #ifdef CONFIG_HARDENED_ATOMIC is sprinkled all over, it
> > makes a huge trainwreck of that file.
> 
> I guess the question was "prefer copy/pasting" vs "sprinkled ifdef". I
> tend to opt for reducing copy/paste, but this is just a code
> organization issue. Likely, then, would be to have two separate
> implementations in different .c files and have the Makefile select the
> desired version.

No, no .c files, this stuff wants to be inline, esp. the unannotated
versions, those typically are a single instruction.

And you don't need to copy/paste, just: #define atomic_wrap_t atomic_t
and use the 'normal' functions.

> > Ideally there'd be only a single #ifdef CONFIG_HARNDED_ATOMIC.
> >
> > I'm also not sure about atomic*_wrap() as an interface, these functions
> > already have far too long names. We could simply overload the existing
> > functions and select based off the argument type.
> 
> There was a concern over catching type errors when building without
> CONFIG_HARDENED_ATOMIC. Again, this is just a code organization issue
> -- I think whatever people prefer is fine. In theory, 0-day will
> quickly catch the corner cases, but I'd love it if the types couldn't
> get mixed up.
> 
> Out of curiosity, how would the arg-type selection look? Are there
> other examples of this already in the kernel?

See static_branch_likely() / static_branch_unlikely().