Fails to build with newer versions of GCC due to '-Werror=unterminated-string-initialization'

[glaubitz]

Trying to build aws-lc-fips-sys as part of efs-utils fails with:

[   56s]   In file included from /home/abuild/rpmbuild/BUILD/aws-efs-utils-2.4.0-build/efs-utils-v2.4.0/src/proxy/vendor/aws-lc-fips-sys-0.13.9/aws-lc/crypto/fipsmodule/bcm.c:148:
[   56s]   /home/abuild/rpmbuild/BUILD/aws-efs-utils-2.4.0-build/efs-utils-v2.4.0/src/proxy/vendor/aws-lc-fips-sys-0.13.9/aws-lc/crypto/fipsmodule/self_check/self_check.c: In function 'boringssl_self_test_fast':
[   56s]   /home/abuild/rpmbuild/BUILD/aws-efs-utils-2.4.0-build/efs-utils-v2.4.0/src/proxy/vendor/aws-lc-fips-sys-0.13.9/aws-lc/crypto/fipsmodule/self_check/self_check.c:1709:38: error: initializer-string for array of 'unsigned char' truncates NUL terminator but destination lacks 'nonstring' attribute (17 chars into 16 available) [-Werror=unterminated-string-initialization]
[   56s]    1709 |   static const uint8_t kAESKey[16] = "BoringCrypto Key";
[   56s]         |                                      ^~~~~~~~~~~~~~~~~~
[   56s]   /home/abuild/rpmbuild/BUILD/aws-efs-utils-2.4.0-build/efs-utils-v2.4.0/src/proxy/vendor/aws-lc-fips-sys-0.13.9/aws-lc/crypto/fipsmodule/self_check/self_check.c:1859:51: error: initializer-string for array of 'unsigned char' truncates NUL terminator but destination lacks 'nonstring' attribute (19 chars into 18 available) [-Werror=unterminated-string-initialization]
[   56s]    1859 |   static const uint8_t kDRBGPersonalization[18] = "BCMPersonalization";
[   56s]         |                                                   ^~~~~~~~~~~~~~~~~~~~
[   56s]   /home/abuild/rpmbuild/BUILD/aws-efs-utils-2.4.0-build/efs-utils-v2.4.0/src/proxy/vendor/aws-lc-fips-sys-0.13.9/aws-lc/crypto/fipsmodule/self_check/self_check.c:1860:38: error: initializer-string for array of 'unsigned char' truncates NUL terminator but destination lacks 'nonstring' attribute (17 chars into 16 available) [-Werror=unterminated-string-initialization]
[   56s]    1860 |   static const uint8_t kDRBGAD[16] = "BCM DRBG KAT AD ";
[   56s]         |                                      ^~~~~~~~~~~~~~~~~~
[   56s]   At top level:
[   56s]   cc1: note: unrecognized command-line option '-Wno-c11-extensions' may have been intended to silence earlier diagnostics
[   56s]   cc1: all warnings being treated as errors

[justsmth]

Hello!

Yes, this is a known issue. It has been fixed on our main branch, but still exists on our active FIPS branch. Because this code is within the boundary of the FIPS module, we cannot directly change it w/o a strong justification.

Which compiler were using when this failure occurred? We believe this failure only occurs with the latest compiler versions. A workaround would be to use an older compiler version when compiling for FIPS. Another workaround might be to set CFLAGS=-Wno-error=unterminated-string-initialization in the build environment.

[glaubitz]

Yes, this is a known issue. It has been fixed on our main branch, but still exists on our active FIPS branch. Because this code is within the boundary of the FIPS module, we cannot directly change it w/o a strong justification.

Couldn't you cherry-pick the patch?

Which compiler were using when this failure occurred?

GCC 15 which is the default C/C++ compiler on openSUSE Tumbleweed and Fedora Rawhide.

We believe this failure only occurs with the latest compiler versions. A workaround would be to use an older compiler version when compiling for FIPS.

I tried that, but CMake insists on using the default compiler, i.e. ignoring the environment variables CC and CXX.

Another workaround might be to set CFLAGS=-Wno-error=unterminated-string-initialization in the build environment.

That doesn't work either, I'm afraid.

[justsmth]

I tried that, but CMake insists on using the default compiler, i.e. ignoring the environment variables CC and CXX

Is there something that's isolating your builds from the environment you are running them in? The CC and CXX environment variables should be respected by CMake.

If you could provide me (or point me to) more complete build output, I can try to dig a little deeper to diagnose.

[cratelyn]

Yes, this is a known issue. It has been fixed on our main branch, but still exists on our active FIPS branch. Because this code is within the boundary of the FIPS module, we cannot directly change it w/o a strong justification.

Couldn't you cherry-pick the patch?

i've been looking into this issue as well. because the fips security policy notes that the aws-lc-rs team "cannot answer questions about FIPS, nor about using AWS-LC in a FIPS-compliant manner", i want to leave a short note regarding why cherry-picking 78c2583 is unfortunately not possible.

NIST's cryptographic module validation program (CMVP) has assigned certificates #4816 and #4759, which respectively outline the security policy for version AWS-LC FIPS 2.0.0 of the AWS-LC library, as a static library and a dynamic library. these two policies outline the module and its cryptographic boundary as follows:

The cryptographic boundary is defined as the AWS-LC Cryptographic Module (static) which is
a cryptographic library consisting of the bcm.o file (version AWS-LC FIPS 2.0.0). This file is
statically linked to the userspace application during the compilation process.

The module components consist of the bcm.o (AWS-LC FIPS 2.0.0), which is dynamically linked to
the userspace application during the compilation process.

"life-cycle assurance" §11.1 notes that "The set of files specified in the archive constitutes the complete set of source files of the validated module. There shall be no additions, deletions, or alterations of this set as used during module build."

it is my understanding that cherry-picking a commit on the within the crypto/fipsmodule directory would constitute a violation of these rules and leave aws-lc-fips-sys dependents out of FIPS 140-3 compliance.