For secure memory clearance, trying to use the native calls whenever

[ghost]

it is possible or a simple barrier.

[sneves]

Is the libtool.m4 change necessary, or would it suffice to take the configure.ac and blake2-impl.h changes?

[ghost]

I would not say necessary but better to cope with modern libtool but we can always discard it if you really wish.

[cemeyer]

I would appreciate this patch, or something similar (to preferentially use explicit_bzero, at least).

In the FreeBSD kernel environment, memset() is implemented strangely. Additionally, we're stuck using old old 2007-era GPL2 binutils on some Tier 2 platforms. As a result, the existing secure_zero_memory construct creates a link error for PowerPC kernels:

ld: blake2s-ref.o(.text+0x2540): R_PPC_PLTREL24 reloc against local symbol
blake2s-ref.o: could not read symbols: Bad value
...
$ .../blake2s-ref.o
...
00002000 t memset
00000000 d memset_v.3522

(Yes, to some extent this is self-inflicted.)

This issue goes away when the following change is used:

static inline void secure_zero_memory(void *v, size_t n)
{
#ifdef __FreeBSD__
  explicit_bzero(v, n);
#else
  static void *(*const volatile memset_v)(void *, int, size_t) = &memset;
  memset_v(v, 0, n);
#endif
}

(This style was chosen to minimize diff without attempting to be fully general. I think David's patch is the better one to include here.)

Thanks!

[devnexen]

@cemeyer I saw earlier you commited your own changes on FreeBSD you can grab this version now if you wish.

[cemeyer]

Perfect! Thank you.

https://svnweb.freebsd.org/base?view=revision&revision=331620