Soliciting input regarding the hardening of a potential data leak

[nhorman]

The background
Some research was recently sent to the openssl project regarding the potential leaking of data on the stack.

On some architectures that make use of various SIMD instructions (specifically AMD Zen4, but other arches may be affected), it is possible that, when various copy functions are used (like memcpy, strcpy, etc). Its possible that, even if the source memory is cleared after the copy, data from the copy may remain in some of the simd registers, spilling onto the stack if lazy linking is performed. This spillage could be benign, but it could also be potentially detrimental if the data in the memcpy operation is sensitive

The analysis
the problem, in an academic sense, is somewhat easy to fix. Some compilers contain an attribute which allows the clearing of used simd (ne all) registers used in a function on exit. It would be somewhat straightforward to apply this attribute to functions performing such copies and solve the problem that way. But that approach has several drawbacks:

1. Its opportunistic - It works on platforms that support the attribute, but not all compilers do, so its effectively best effort
2. Its incomplete - It cleans up users of those functions, but leaves open the possibility of other locations that don't opt into that copy function, both within openssl and applications linking against it. It also doesn't account for locations that might have the compiler emit instructions using simd registers as part of any optimization
3. Its a performance impact - While we've not measured the performance impact yet, it seems clear that, when used in a general sense, constantly clearing registers during copy operations is going to impact performance

Additional information
it should be noted that this problem was found outside of openssl. There is no specific known attack on openssl using this discovery. It also should be noted that exploitation of this would be a side channel attack, requiring local access to the system. As such this is being looked at as a hardening effort, rather than a security bug.

The question
We are soliciting input for what to do about this. The options currently are:

1. Augment our OPENSSL_memcpy/dup/strcpy functions to clear registers on exit, and opportunistically mitigate the problem where possible, accepting the performance impact

2. Create variants of the above functions with register clearing attributes set, and make use of them in places where we think sensitive data might be in a register, updating when/if additional locations are found that may leak sensitive data