On Fri, Oct 23, 2020 at 11:39:27AM -0400, Arvind Sankar wrote: > On Wed, Oct 21, 2020 at 09:36:33PM -0700, Eric Biggers wrote: > > On Tue, Oct 20, 2020 at 04:39:52PM -0400, Arvind Sankar wrote: > > > Without the barrier_data() inside memzero_explicit(), the compiler may > > > optimize away the state-clearing if it can tell that the state is not > > > used afterwards. At least in lib/crypto/sha256.c:__sha256_final(), the > > > function can get inlined into sha256(), in which case the memset is > > > optimized away. > > > > > > Signed-off-by: Arvind Sankar <nivedita@xxxxxxxxxxxx> > > > > Reviewed-by: Eric Biggers <ebiggers@xxxxxxxxxx> > > > > Maybe get the one in arch/arm64/crypto/sha3-ce-glue.c too? > > > > - Eric > > Hm, there are a few more as well like that. But now I'm thinking it's > only the generic sha256.c that may be problematic. The rest of them are > in _final() functions which will be stored as function pointers in a > structure, so there should be no risk of them getting optimized away? When clearing memory because "it may be sensitive" rather than "it's needed for the code to behave correctly", I think it's best to use memzero_explicit() to make the intent clear, even if it seems that memset() is sufficient. Also keep in mind that support for compiling the kernel with LTO (link-time optimization) is being worked on (and some people already do it), which results in more code being optimized out. - Eric
