memset suggestion.

[Ben Lindstrom]

On Fri, 8 Nov 2002, Rick Jones wrote:

> > > Can you enlighten us why it is bad?  I'm not a compiler guru...
> >
> > Everyone uses memset() to clear inmemory passwords so people can't go
> > digging around in /dev/kmem.  If memset() is optimizated out then the
> > password still stick around in memory until it is reallocated and reused.
> >
> > But this is only half of the issue.  It could still be in registers or in
> > the stack.  Which memset() does not solve.
>
> Which is why the optimization is not "bad" but perhaps "unfortunate"
> instead. Within the context of the output of the program, optimizing
> the memset away is fine.
>

Don't know.. I guess I expect too much from compilers.  I expect:

1. Code I write stays written.  if I put a memset() in.. I put it in for a
damn good reason.=)  I hate when computers second guess me.

2. I expect the compiler to produce reasonable and predictable
optimization.  GCC fails at both of these at higher optimizations.

3. If a compiler decides to yank stuff I wrote out.. I expect it to tell
me.  "warning: xxx() removed as dead code"

that way I at least know what the compiler is removing of my code so I can
either report it as a bug/misfeature or correct my code so it does not
remove it.

Maybe I am asking too much.=)


> It seems that the real problem here (?) is an operating environment
> that allows access to others to the stack/heap/registers/whatever.
>
> > Personally everyone I see that compiles software at greater than -O2
> > I tend to LART them over the head with either the bat book or 'hack
> > proofing your network'.  That seems to get their attention to
> > explain why higher levels of -O may not be what the want (mainly
> > when they come whining about their code not working..<sigh>).
>
> Of course, then when the do compile at only O2, they start to complain
> about the performance of the application... Now where or not the app
> not working at higher optimization levels is a bug in the app or a bug
> in the optimizer is another discussion...
>

if your still having 'preformance' issues at -O2.  I'd seriously look at
why.  Most fall into:

1. Lack of OS support of critical features (Ala /dev/random)
2. Lack of clean well written (programmer optimized) critical functions
3. Lack of processor support for critical features (Ala D/H key
   generation on SS20)
4. Bad/overcomplex design
5. Not enough ram, too slow of processor, bad hardware design, etc.

The last thing you want is to crank up -O.  Entrusting your code to a
random compiler is asking for trouble.

If the compiler is finding dead code.  It really should be telling the
programmer so they can decide why and to ensure if it is a valid code
branch that it is not optimized away.

As I said.. maybe I expect too much from the compiler.

- Ben

> rick jones
> quixotic booster of provile-based optimization and higher levels :)
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>