Page MenuHome GnuPG

Run integrity checks + selftests from library constructor in FIPS
Open, Needs TriagePublic

Description

This patch is based on the following Fedora patch:

https://src.fedoraproject.org/rpms/libgcrypt/blob/rawhide/f/libgcrypt-1.8.3-fips-ctor.patch

It will probably require some tweaks to make it working/ignore this on platforms that do not support constructors or conditionalized it based on a configuration option if this could not be allowed universally.

Edit: Updated the patch with more relevant information that I gathered from the other scattered patches like the following:

Unfortunately, there were quite interconnected and using only one of these does not make sense.

There are still some outstanding issues of this approach. I am not sure how much relevant is FIPS for you on Windows or other places that do not use dynamic library constructor. Similarly in the commit message, there is described one more issue with the secure memory, that will probably require some cleanup.

This is mostly first version to start discussion if something like this can go in

Details

Version
master

Event Timeline

It seems for me that the patches to random/ was written in old days.

  • Now, we have getentropy in libc
    • This is most reliable one
    • better than urandom, because it may block when kernel is not yet seeded
    • better than random, because it never blocks once kernel is seeded
  • So, the real path in rndlinux.c is actually, call to getentropy
  • No access to /dev/random or /dev/urandom any more, in fact
  • Although old code remains, non-touched
    • like use of syscall when getentropy function is not available

I'd like to know the purpose or original problems to solve by the patches to random/, to merge the work.

Can we focus on non-random/ parts at first, then come back to random/?
In this case, the problem to solve looks like:

  • global_init and call of _gcry_fips_run_selftests under no_secure_memory=1