Cleanup for cryptographic algorithms vs. compiler optimizations

[Bernd Walter]

On Sat, Jun 12, 2010 at 07:35:26PM +0200, Dag-Erling Smørgrav wrote:
> Bernd Walter <ticso at cicely7.cicely.de> writes:
> > I'm not sure when removing a memset is allowed.
> 
> Always, if the compiler can determine that the data will not be used
> later.

I'm at least sure that the compiler can't if it is linked from another
object file.
The problem with memset is that the compiler has an internal implementation.
On the other hand I wonder what the deep sense is to clear memory which
is unused later.
I know that crypto code can be tricky sometimes, but if someone is willing
to explain the specific reason my curiosity would be satified.

> In more general terms, the compiler is allowed to make any changes it
> likes to the program as long as the end result behaves exactly like it
> would if it hadn't been changed.  This is called the "as if" rule.  For
> instance, if you call printf() or fprintf() with a format string that
> does not contain any conversion specifiers, gcc will call gets() or
> fgets() instead.

Amazing - this is one of the things which can get nasty if you try some
kind of microtuning.
Recently I had to implement my own atoi on a controller because using the
library one magically had blown my RAM usage by 1k on a controller with
just 8k RAM.

> > Maybe passing volatile pointers might be enough.
> 
> You can't pass a volatile pointer to memset.

Of course not - my fault - it takes non volatile pointers per definition.

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