On Thu, Dec 01, 2011 at 05:45:25PM +, David Laight wrote:
> On Tue, Nov 29, 2011 at 09:23:20PM +0100, Joerg Sonnenberger wrote:
> > On Tue, Nov 29, 2011 at 09:09:38PM +0100, Matthias Drochner wrote:
> > > Anyway, here is a first cut on an "explicit_bzero" function
> > > which doesn't get optimi
On Thu, Dec 01, 2011 at 05:45:25PM +, David Laight wrote:
> > > Anyway, here is a first cut on an "explicit_bzero" function
> > > which doesn't get optimized away. I've put it to src/common
> > > because the same thing makes sense in the kernel too.
> > > Comments?
> >
> > Just make it a
On Tue, Nov 29, 2011 at 09:23:20PM +0100, Joerg Sonnenberger wrote:
> On Tue, Nov 29, 2011 at 09:09:38PM +0100, Matthias Drochner wrote:
> > Anyway, here is a first cut on an "explicit_bzero" function
> > which doesn't get optimized away. I've put it to src/common
> > because the same thing makes s
On Tue, Nov 29, 2011 at 09:09:38PM +0100, Matthias Drochner wrote:
> Anyway, here is a first cut on an "explicit_bzero" function
> which doesn't get optimized away. I've put it to src/common
> because the same thing makes sense in the kernel too.
> Comments?
Just make it an alias on memset. That's
dholland-sourcechan...@netbsd.org said:
> You also want to take steps to make sure that the zeroed cache line is
> flushed out.
This would be good, but it is a bit hard on x86 from userland
because wbinv is a privileged instruction. Would need a system
call.
Anyway, here is a first cut on an "exp
m.droch...@fz-juelich.de said:
> a disassembly of MD5Final() on i386 shows that the final zeroing is
> present in the binary
OK, this is no surprise. At this point the compiler can't know that
it is a dead store.
best regards
Matthias
--
On Tue, Nov 29, 2011 at 07:14:38PM +0100, Matthias Drochner wrote:
> > the memset() is likely to get optimized away by the compiler anyway.
> > It's a dead store after all.
>
> It might be by luck, but a disassembly of MD5Final() on i386
> shows that the final zeroing is present in the binary
jo...@britannica.bec.de said:
> the memset() is likely to get optimized away by the compiler anyway.
> It's a dead store after all.
It might be by luck, but a disassembly of MD5Final() on i386
shows that the final zeroing is present in the binary.
Generally I agree that we should make this kind o
On Tue, Nov 29, 2011 at 06:40:17PM +0100, Matthias Drochner wrote:
>
> jo...@britannica.bec.de said:
> > Well, the way it is done, it won't help.
>
> What do you mean - a duplication of efforts?
No, just that the memset() is likely to get optimized away by the
compiler anyway. It's a dead store
jo...@britannica.bec.de said:
> Well, the way it is done, it won't help.
What do you mean - a duplication of efforts?
Just noticed this myself... I'm not sure it is a good idea to
do this in MD5Final because it might be unnecessary if the
hash is just used for indexing or so. In addition, this is
On Tue, Nov 29, 2011 at 01:18:52PM +, Matthias Drochner wrote:
> Module Name: src
> Committed By: drochner
> Date: Tue Nov 29 13:18:52 UTC 2011
>
> Modified Files:
> src/lib/libcrypt: md5crypt.c
>
> Log Message:
> zero out hash context after use, to avoid traces in RAM
> (hint
11 matches
Mail list logo
