On 10/10/2014 11:20 AM, Andrew Haley wrote:
On 09/10/14 21:52, Ángel González wrote:
The compiler would need to know that memset_s is special (either
intrinsically or thorugh eg. function attributes). Either way, IMHO
an advanced knowledge allowing to optimize it out would be a
violation of K.3.7.4.1.
It would be a perverse thing to do and goes against intent, but we
again fall into the problem of defining an access. But this is
irrelevant anyway: even if a key is stored in an array X in the source
code and the array X is later wiped with memset_s(), there is
absolutely nothing to force the compiler to use X during the
computation: it may well store the key somewhere else altogether.
It's not even that hard to come up with an example where calling
memset_s causes the creation of another copy which is the only one which
is being cleared:
#include <stddef.h>
struct key {
unsigned long long low;
unsigned long long high;
};
struct key get_key(void);
void use_key(struct key);
void secure_clear_memory(void *, size_t);
void
without_clear(void)
{
struct key k;
k = get_key();
use_key(k);
}
void
with_clear(void)
{
struct key k;
k = get_key();
use_key(k);
secure_clear_memory(&k, sizeof(k));
}
without_clear:
subq $8, %rsp
call get_key
movq %rdx, %rsi
movq %rax, %rdi
call use_key
addq $8, %rsp
ret
with_clear:
subq $24, %rsp
call get_key
movq %rax, %rdi
movq %rdx, %rsi
movq %rax, (%rsp)
movq %rdx, 8(%rsp)
call use_key
movq %rsp, %rdi
movl $16, %esi
call secure_clear_memory
addq $24, %rsp
ret
--
Florian Weimer / Red Hat Product Security
