Re: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse
> 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
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
Re: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse
>> We do have assembler versions for most CPI's. > > In the context one can also add that the kind of optimization that could > omit memset invocation *has to* rely on deep inter-procedural > *multi-file* analysis. If compiler is given mem_clr.c alone, and it > doesn't look at it when compiling other modules, it won't be able to > eliminate the call. I said it several times already that no security > software should encourage deep inter-procedural optimizations such as > -flto (or -ipo in Intel compiler context). > > For reference code generated by Intel compiler (when it's compiling > mem_clr.c alone) is equivalent to > > f = memset_func; > if (f==memset) _intel_fast_memset(args) > else (*f)(args) 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). I.e. it actually does *not* reference *that* pointer to memset!!! Which in turn means that report is inaccurate claiming that compiler fulfills the contract by always referencing the pointer [just not calling the procedure]. It doesn't, and one can probably argue that compiler doesn't comply with the standard. Or can one? What's going on there? Trouble is that pointer is also declared as const in that example. But what does "const volatile" even mean? In physical world it's actually a meaningless combination, nothing can be both. And even logically it's meaningless. And if so, can one actually blame compiler for making an impossible choice? In addition one should not forget that the referred snippet declares "erase" static, which means that it ought to be a header that gets included, which in turn means that inter-procedural *multi-file* analysis is not required to eliminate it. To summarize. OpenSSL fall-back[!] OPENSSL_cleanse subroutine is different from snippet presented in report in question in two essential ways: - pointer to memset is *not* const (which by the way is not a coincidence, at least in sense that I would have argued against declaring it volatile const, and I likely did, just can't actually recall); - it's in separate file (and hence it takes deep IPA to even nominate it for optimization, which we shouldn't/don't recommend); And once again, not to forget that it's a fall-back[!] procedure for platforms that don't have assembly pack. [Well, with exception for arm64 in 1.0.2. I mean arm64cpuid.S in 1.0.2 doesn't have OPENSSL_cleanse. Should I back-port one from master? And MIPS. I mean MIPS assembly pack doesn't have "cpuid" module...] -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse
> We do have assembler versions for most CPI's. In the context one can also add that the kind of optimization that could omit memset invocation *has to* rely on deep inter-procedural *multi-file* analysis. If compiler is given mem_clr.c alone, and it doesn't look at it when compiling other modules, it won't be able to eliminate the call. I said it several times already that no security software should encourage deep inter-procedural optimizations such as -flto (or -ipo in Intel compiler context). For reference code generated by Intel compiler (when it's compiling mem_clr.c alone) is equivalent to f = memset_func; if (f==memset) _intel_fast_memset(args) else (*f)(args) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse
We do have assembler versions for most CPI's. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4684 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse
We do have assembler versions for most CPI's. Closing ticket. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse
Hi, Please read: http://www.metzdowd.com/pipermail/cryptography/2016-September/030151.html We use the same construct for our OPENSSL_cleanse, but I think we also have assmebler versions. Kurt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4684 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
