The configure option --enable-hmac-binary-check, which defines ENABLE_HMAC_BINARY_CHECK macro seems to have never worked, and keeps status of expressing the concept;
dladdr requires an address as the first argument, but currently it's symbol name.
SUSE has a patch, but... AFAIK, it is wrong for ELF system to load same shared object/libraries more than once (as its name space is single). So, use of dlopen here is wrong.
| rC libgcrypt | |||
| rC17f9eb20c94f build: Fix excess quotation to enable config.status --recheck works. | |||
| rC10e02b90f65f build: Support specifying HMAC key by --enable-hmac-binary-check. | |||
| rC070935965763 build: Use KEY_FOR_BINARY_CHECK for --enable-hmac-binary-check. | |||
| rC9511f469363b build: Add hmac256.h to distribution. | |||
| rCc9acca865ba4 hmac: Don't have the second implementation of hmac256. | |||
| rCc11788e5641b fips: Don't use gcry_check_version for integrity check any more. | |||
| rCf02dc5235e47 fips: Use a .rodata1 section integrity check with hmac256. | |||
| rC24aaded244a2 build: Generate hash for integrity check with hmac256 (2). | |||
| rC3c89aad4a0d7 build: Generate hash for integrity check with hmac256. | |||
| rCca6797c5c5c6 fips: Fix check_binary_integrity. | |||
Just for the records, the whole HMAC thing including the special dlopen trick used to work fine when we did the original FIPS support.
We have the same patch (including the hmac key and we use the switch. The reasoning on our side was to be compatible with fipscheck, but it is no longer used since last year and we use just the hmac256 tool:
https://src.fedoraproject.org/rpms/libgcrypt/blob/rawhide/f/libgcrypt.spec#_121
Let me check if there is some specific requirement for the hmac files in FIPS 140-3
Ah... I realized that HMAC integrity check with dladdr (using address of constant string) might work (at some point) to determine the filename of libgcrypt.so, when/if glibc implementation allows searching with address of constant string. So, my claim "never worked" was wrong.
Now, with rCc9acca86, we use dladdr1 to determine the file name of libgcrypt.so, and the offset in the file for HMAC value. Please note that: The HMAC value is written in libgcrypt.so itself (it was an independent file in the past, named like .libgcrypt.so.20.3.3.hmac). In current implementation, we use .rodata1 section for that, following some practice of embedded system. If it is not good, we can change the way where we keep the HMAC value.
This feature is only supported for GNU/Linux with shared library (not for static link), because dl functions are non-POSIX (or not-yet POSIX) thing.
While I don't know if runtime integrity check is required or not by FIPS 140,
I checked OpenSSL, and it has such a check in openssl/providers/fips. The FIPS module configuration file which has the module checksum by HMAC is generated by openssl fipsinstall command.
iirc Uli Drepper added a hack to dladdr which we made use of. Seems to be integrated into dladdr1 now.
I tried to generate a tarball from master and I failed to build the hmac256 binary because the hmac256.h was not packaged into the dist tarball in master. If hmac256 should be standalone binary, I propose it should not need have a separate header file:
Other option might be adding back the header file, probably to EXTRA_DIST in Makefile.am to unbreak the build. What do you think @gniibe ?
Thank you for pointing out. Since hmac256.{c,h} can be used by others, I think that it is better to keep those two files, instead of merging it into one.
https://www.gnu.org/software/automake/manual/html_node/Headers.html#Headers says:
However when the header actually belongs to a single convenience library or program, we recommend listing it in the program’s or library’s _SOURCES variable...
So, I'm adding hmac256.h to hmac256_SOURCES.
Thanks. This looks good to me.
I tested also the hmac binary check itself with the hmac inside of the library and all seems to work great.
I only found quite cumbersome the way to change the key. Its hardcoded in the source code on two places so when I need to use different key, I need to patch it in two places. I would suggest to provide a configure switch with the key, which would be used both for hmac generation (variable in src/hmac256.c) and verification (constant in src/fips.c).
I push a change: rC070935965763: build: Use KEY_FOR_BINARY_CHECK for --enable-hmac-binary-check..
I am trying to support configure option like: --enable-hmac-binary-check="I know engineers. They love to change things.", but I need to learn quoting in autoconf/automake/shell/make, so that it can work correctly.
Now configure with
--enable-hmac-binary-check="I know engineers. They love to change things." works.