Re: Cleanup for cryptographic algorithms vs. compiler optimizations

On Sat, Jun 12, 2010 at 05:35:28PM +0200, Ulrich Spörlein wrote:
> On Fri, 11.06.2010 at 21:37:29 +0200, Dag-Erling Smørgrav wrote:
> > Ulrich Spörlein <uqs_at_spoerlein.net> writes:
> > > optimizing compilers have a tendency to remove assignments that have
> > > no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot of
> > > zeroing variables, which is however optimized away.  [...]  Is there a
> > > canonical way to zero those variables and should we use them (memset
> > > perhaps? what are the performance implications?)
> > 
> > If you stick these variables in a struct, you can memset the struct to
> > zero them; if there are many of them, it may be faster than zeroing them
> > individually.
> > 
> > Alternatively, you can use something like this:
> > 
> > #define FORCE_ASSIGN(type, var, value) \
> >         *(volatile type *)&(var) = (value)
> 
> Interesting trick, thanks. I'll try this ...

I'm not sure when removing a memset is allowed.
Maybe passing volatile pointers might be enough.
And I'm happy to be corrected from in deep experts - my knowledge is
more from practical microcontroller programming.
The problem with memset is that is is inlined by at least gcc and
inlined functions are included in the optimizations.

But calling my_abolsutely_not_inlineable_memset should work IMHO.
In other words: declare a local memset function, which is declared
(in compiler specific words) as not being inlineable, which itself calls
memset you should be safe, since the function doesn't know why it does
the memset it can't be removed and the caller doesn't know anything about
the called function.
A portible way would be to have this function in a separate .c file,
which prohibits inlining.

C++ has the concept of volatile member functions, but this is a
slightly different thing.

-- 
B.Walter <bernd_at_bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.