Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 10 Nov 2016 22:46:30 +0100
From: Peter Zijlstra <>
To: Kees Cook <>
Cc: Elena Reshetova <>,
	"" <>,
	Arnd Bergmann <>, Thomas Gleixner <>,
	Ingo Molnar <>,
	"H. Peter Anvin" <>,
	Will Deacon <>,
	Hans Liljestrand <>,
	David Windsor <>
Subject: Re: [RFC v4 PATCH 12/13] x86: implementation for HARDENED_ATOMIC

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().

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.