On Fri, 19 Apr 2024, Zack Weinberg wrote: > On Fri, Apr 19, 2024, at 2:45 PM, Paul Eggert wrote: > > On 4/19/24 11:04, Mikulas Patocka wrote: > >> There's already "explicit_bzero", so maybe we could add > >> "explicit_memcpy" > > > > Where would this stop? Wouldn't we also need explicit_memcmp, > > explicit_memmove, explicit_mempcpy, etc.? Pretty much any function that > > looks at memory could have the problem. Even C source code that doesn't > > invoke any C library function could have the problem. > > As I recall, one of the arguments for _not_ adding explicit_bzero to glibc > was that we couldn't guarantee copies of the secret data wouldn't hang > around in registers. bzero and memset have no reason to read data from memory, they only need to overwrite that memory. This makes them different from memcpy. In the caller of memset/memcpy, sure, copies of that data may be present on registers. > Is a hypothetical function __attribute__((clear_call_clobbered_regs_on_exit)) > what we need here instead, maybe? As indicated upthread, there's a non-hypothetical __attribute__((zero_call_used_regs)), unless you mean something else? Alexander
