Optimized memcmp failure.

[Dimitry Andric]

On 2010-08-10 10:08, Clement LECIGNE wrote:
> It describes various memcmp() implementations of some OSes. FreeBSD is
> mentionned at the end of the post and it warns about the fact that gcc
> uses its own builtin memcmp() function when optimization (from O1 to O3)
> is set. Unfortunately the gcc builtin memcmp() seems less optimized (at
> least for i386 and amd64) than the FreeBSD memcmp() implementation (found
> in libc).

Some of the libc memcmp/cpy/etc implementations are hand-optimized
assembly, and those might very well be faster than the built-in ones,
for the general case.

However, in some cases, the compiler has more information about the
context in which a copy operation is taking place, and might be able to
simplify the copy so much that it is more efficient than the libc
memcpy.

That said, the mentioned security issue is about sensitive information
(the length of secret keys, etc) possibly being derived from timing
memcpy calls.  In that case it would probably even be better to let the
compiler inline that code, since you cannot simply hook the libc memcpy
function anymore. :)

Better solutions for this (and similar issues) are more costly: you have
to go through all code handling sensitive data carefully, identify the
memcpy/memcmp/etc calls that could possibly leak secret information,
and replace those with 'timing insensitive' versions.  OpenBSD just went
through a whole bunch of these checks...