need secure memset/memzero

[rurban]

See SecureZeroMemory, but the mingw variant misses an compiler barrier and memory barrier (a full mfence).
This is a winnt.h/WinBase.h macro to an inlined (header-only) RtlSecureZeroMemory, which is a worse version than our mem_prim_set(). See the mingw sources. The compiler barrier might be there with the volatile dest, but this is a big maybe. It just uses a volatile dest and then loops by char. On x86_64 it uses stosb. Our implementation is much better for larger sizes, and equally secure.

On glibc maybe try explicit_bzero, elsewhere use a volatile dest to avoid compiler optimizations skip the memset_s/memzero_s/mem_prim_set call.

But explicit_bzero is just a memset with a barrier:

memset (s, '\0', len);
/* Compiler barrier.  */
asm volatile ("" ::: "memory");

Since most speculative CPU's are broken regarding out of order memory insns, prefer mfence over the simple compiler barrier. (Spectre, Meltdown). We need to ensure that no load can be done on stored memset's to avoid leaking private/secure data. A compiler barrier just ensures that the compiler will not re-order a load before the store, and will dump all regs to memory. But we have a HW problem also.

See e.g.

• https://wiki.sei.cmu.edu/confluence/display/c/MSC06-C.+Beware+of+compiler+optimization
• https://fahrplan.events.ccc.de/congress/2018/Fahrplan/events/9788.html
• https://stackoverflow.com/questions/12183311/difference-in-mfence-and-asm-volatile-memory