memset suggestion.

[Ben Lindstrom]

On Fri, 8 Nov 2002, Corinna Vinschen wrote:

> On Thu, Nov 07, 2002 at 10:14:50PM -0600, Ben Lindstrom wrote:
> >
> > Since 3.x is rolling out with -fno-builtin-<comand> support maybe we
> > should test for 3.x and set -fno-builtin-memset which should stop gcc from
> > optimizing it away.  And maybe everyone should look for the same feature
> > in their favorite compiler.
> >
> > There is not much OpenSSH can do about bad compilers optimization, but
> > that is the only reasonable way to stop it starting in the 3.x series of
> > gcc.
>
> 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.  I saw a post on OpenBSD
mailinglist that gave an example of a function that may work for clearing
all three and that should not be optimized out.  I'll dig around for it
and repost it here.

I don't know how much action should be taken on this.  Hacking around one
gcc bug always leads to another version of gcc horking up a furball or
some other compiler whining and moaning about it.

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>).

- Ben