[cfe-dev] Zero'ing Registers on Function Return

[Szabolcs Nagy]

* Russell Harmon <eatnumber1 at google.com> [2014-09-12 17:02:16 +0000]:
> I'm somewhat of a fan of Paul's solution - disallowing calls to non
> annotated functions.

considering the abstract machine the compiler is allowed to make
transformations that adds new libc function calls in the code
which have no annotations

which is not what you want here, hence you need to be careful
how to specify the behaviour of the attribute

> Would clearing the stack implicitly help all that much if the programmer
> has already properly cleared the sensitive via a call to memset_s?

as any other function in annex k memset_s depends on global state
in case of runtime-constraint violation which is, unlike ub, part
of the semantics of the function and hence users can rely upon

since constraint handler is global state it cannot be reasonably
set by a library so i would not recommend the use of annex k
functions in general (there are other problems with functions in
annex k but that's a different topic)

> I'm not trying to deal with every case. I'm specifically trying to deal
> with hardening in case of memory disclosure bugs. An attacker e.x. reading
> from the swap device directly is outside of the scope of this protection,
> as you require more than just a memory disclosure to exploit.

ok

> > what is probably doable is a non-recursive version (which still can be a
> > help to crypto code, but harder to use correctly). however i suspect even
> > that's non-trivial to specify in terms of the abstract machine of c
> >
> > for recursive things i think the type system has to be invoked: eg a
> > sensitive type qualifier that marks state which the compiler has to
> > cleanup after.
> >
> 
> I'm not clear on why disallowing calls to non-annotated functions from
> within an annotated function won't handle these issues.

eg.

  struct s a = b;

will often translate to memcpy(&a, &b, size), ie a libc call

memcpy will not be annotated as 'cleanup the regs' and it
can clearly cause info leak

it would be annoying if the compiler did such transformation
and then failed to compile the code

so i think a bit more is needed than 'disallow unannotated calls'