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... _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
