> Actually it should also be noted that snippet presented in originally
> mentioned
> http://www.metzdowd.com/pipermail/cryptography/2016-September/030151.html
> is actually compiles as just
>
> _intel_fast_memset(args)
>
> by Intel compiler 17.0 (a.k.a. 2017).
Second look at code generated by icc 17 revealed following. Consider
#include <string.h>
static void *(*volatile const deleter)(void*,int,size_t)=memset;
static void erase(void *buf,size_t len){deleter(buf, 0, len);}
void foo()
{ char t[6];
erase(t,sizeof(t));
}
void bar()
{ char t[6];
memset(t,0,sizeof(t));
}
As it turns out icc 17 generates *identical* code for *both* foo() and
bar(), i.e. foo doesn't reference deleter, but both[!] do wipe t[6].
Moreover, they do it in so called red zone, i.e. above stack pointer,
without allocating frame. In other words icc 17 *apparently* considers
_intel_fast_memset as memset_s. This by the way also differs from claim
in original report. It might happen that reporter refers to different
version... And just in case, for reference, gcc (as well as clang)
reduces bar() to single return instruction, i.e. as if t is not there,
while foo() does dereference deleter.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
