linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: mancha security <mancha1@zoho.com>
Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org,
	Theodore Ts'o <tytso@mit.edu>,
	Stephan Mueller <smueller@chronox.de>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>,
	Mark Charlebois <charlebm@gmail.com>,
	Behan Webster <behanw@converseincode.com>
Subject: Re: [PATCH crypto-2.6] lib: make memzero_explicit more robust against dead store elimination
Date: Thu, 30 Apr 2015 01:43:07 +0200	[thread overview]
Message-ID: <55416C8B.1070909@iogearbox.net> (raw)
In-Reply-To: <20150429145400.GA12861@zoho.com>

On 04/29/2015 04:54 PM, mancha security wrote:
> On Wed, Apr 29, 2015 at 04:01:19PM +0200, Daniel Borkmann wrote:
>> On 04/29/2015 03:08 PM, mancha security wrote:
>> ...
>>> By the way, has anyone been able to verify that __memory_barrier
>>> provides DSE protection under various optimizations? Unfortunately, I
>>> don't have ready access to ICC at the moment or I'd test it myself.
>>
>> Never used icc, but it looks like it's free for open source projects;
>> I can give it a try, but in case you're faster than I am, feel free
>> to post results here.
>
> Time permitting, I'll try setting this up and post my results.

So I finally got the download link and an eval license for icc, and
after needing to download gigbytes of bloat for the suite, I could
finally start to experiment a bit.

So __GNUC__ and __INTEL_COMPILER is definitely defined by icc, __ECC
not in my case, so that part is as expected for the kernel header
includes.

With barrier_data(), I could observe insns for an inlined memset()
being emitted in the disassembly, same with barrier(), same with
__memory_barrier(). In fact, even if I only use ...

static inline void memzero_explicit(void *s, size_t count)
{
   memset(s, 0, count);
}

int main(void)
{
   char buff[20];
   memzero_explicit(buff, sizeof(buff));
   return 0;
}

... icc will emit memset instrinsic insns (did you notice that as
well?) when using various optimization levels. Using f.e. -Ofast
-ffreestanding resp. -fno-builtin-memset will emit a function call,
presumably, icc is then not allowed to make any assumptions, so given
the previous result, then would then be expected.

So, crafting a stupid example:

static inline void
dumb_memset(char *s, unsigned char c, size_t n)
{
         int i;

         for (i = 0; i < n; i++)
                 s[i] = c;
}

static inline void memzero_explicit(void *s, size_t count)
{
   dumb_memset(s, 0, count);
   <barrier-variant>
}

int main(void)
{
   char buff[20];
   memzero_explicit(buff, sizeof(buff));
   return 0;
}

With no barrier at all, icc optimizes all that away (using -Ofast),
with barrier_data() it inlines and emits additional mov* insns!
Just using barrier() or __memory_barrier(), we end up with the same
case as with clang, that is, it gets optimized away. So, barrier_data()
seems to be better here as well.

Cheers,
Daniel

  reply	other threads:[~2015-04-29 23:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-28 15:22 [PATCH crypto-2.6] lib: make memzero_explicit more robust against dead store elimination Daniel Borkmann
2015-04-28 21:37 ` Stephan Mueller
2015-04-29 13:08 ` mancha security
2015-04-29 14:01   ` Daniel Borkmann
2015-04-29 14:54     ` mancha security
2015-04-29 23:43       ` Daniel Borkmann [this message]
2015-04-30  6:17         ` mancha security
2015-04-29 14:56     ` Daniel Borkmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55416C8B.1070909@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=behanw@converseincode.com \
    --cc=charlebm@gmail.com \
    --cc=hannes@stressinduktion.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=mancha1@zoho.com \
    --cc=smueller@chronox.de \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).