Optimising away memset() calls?

[Florian Weimer]

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