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
next prev parent 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).