From: Bill Davidsen <davidsen@tmr.com>
To: linux-kernel@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Subject: Re: [PATCH v1] compiler: prevent dead store elimination
Date: Sun, 28 Feb 2010 19:36:07 -0500 [thread overview]
Message-ID: <4B8B0BF7.4060105@tmr.com> (raw)
In-Reply-To: <20100228095520.GA29531@one.firstfloor.org>
Andi Kleen wrote:
>> Every byte in the [p,p+n[ range must be used. If you only use the
>> first byte, via e.g. asm("" :: "m"(*(char*)p)), then the compiler
>> _will_ skip scrubbing bytes beyond the first. This works with
>> gcc-3.2.3 up to gcc-4.4.3.
>
> You forgot to credit Mikael who did all the hard work figuring
> this out?
>
>> /*
>> + * Dead store elimination (DSE) is an optimization that may remove a write to
>> + * a buffer that is not used anymore. Use ARRAY_PREVENT_DSE after a write when
>> + * the scrub is required for security reasons.
>> + */
>> +#define ARRAY_PREVENT_DSE(p, n) \
>
> Maybe it's just me, but the name is ugly.
>
>> + do { \
>> + struct __scrub { char c[n]; }; \
>
>
> Better typeof(*p)[n]
>
>> +++ b/include/linux/compiler-intel.h
>> @@ -14,9 +14,11 @@
>> * It uses intrinsics to do the equivalent things.
>> */
>> #undef barrier
>> +#undef ARRAY_PREVENT_DSE
>> #undef RELOC_HIDE
>>
>> #define barrier() __memory_barrier()
>> +#define ARRAY_PREVENT_DSE(p, n)
>
> Who says the Intel compiler doesn't need this?
>
> I'm sure it does dead store elimination too and it understands
> gcc asm syntax.
>
According to the Intel forum, it not only doesn't, but a request for this as a
feature was rejected, so it won't. Or am I misreading this?
http://software.intel.com/en-us/forums/showthread.php?t=46770
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
next prev parent reply other threads:[~2010-03-01 0:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-27 20:47 [PATCH v1] compiler: prevent dead store elimination Roel Kluin
2010-02-28 9:55 ` Andi Kleen
2010-02-28 15:34 ` [PATCH v2] " Roel Kluin
2010-03-01 9:29 ` Mikael Pettersson
2010-03-02 12:17 ` Andi Kleen
2010-03-03 23:16 ` [PATCH v3] " Roel Kluin
2010-03-02 12:24 ` [PATCH v2] " Andi Kleen
2010-03-01 0:36 ` Bill Davidsen [this message]
2010-03-01 5:15 ` [PATCH v1] " Arjan van de Ven
2010-03-01 9:32 ` Mikael Pettersson
2010-03-01 9:33 ` Alexey Dobriyan
2010-03-01 22:27 ` Andi Kleen
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=4B8B0BF7.4060105@tmr.com \
--to=davidsen@tmr.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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