openssl: The fipsmodule.cnf to be installed cannot be created by openssl fipsinstall in cross-compiled builds
#13684 broke cross-compiled builds by making install_fips automatic.
Our project cross-compiles OpenSSL for ARM on x86_64 as part of a larger distribution. Other open-source components of this distribution have dependencies on OpenSSL. As such, we depend on the install target working properly so we can build OpenSSL and install the artifacts into a staging directory which we then specify on the “configure” command lines when we subsequently build those other components. Prior to #13684 the install target completed successfully (and providers/fips.so was getting installed into the correct location). Now the install target in our cross-compile builds fails with:
make[2]: *** No rule to make target 'providers/fipsmodule.cnf', needed by 'install_fips'. Stop.
This aborts installation and prevents the copying of fips.so into our staging directory.
We use this command line to configure OpenSSL:
./Configure linux-generic32 -DL_ENDIAN -DOPENSSL_NO_COMP shared --prefix=/usr --openssldir=/conf/openssl enable-fips no-zlib no-comp no-tests
It appears that no-tests prevents the creation of the providers/fipsmodule.cnf Makefile target (which we can’t actually build anyway when cross-compiling). Since providers/fipsmodule.cnf is now a prerequisite for installing fips.so into our staging directory, that module is missing from our final product.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 26 (26 by maintainers)
Commits related to this issue
- Refactor how providers/fipsmodule.cnf is generated It was made to only be generated for testing. However, it was also referred to from the 'install_fips' target, which suggests that it should be gen... — committed to levitte/openssl by levitte 3 years ago
- Rework how providers/fipsmodule.cnf is produced First of all, we have concluded that we can calculate the integrity checksum with a simple perl script. Second, having the production of providers/fip... — committed to levitte/openssl by levitte 3 years ago
- TEST: Add test specific fipsmodule.cnf, and use it We add the concept of preparation recipes, which are performed unconditionally. They are all expected to match the pattern test/recipes/00-prep_*.t... — committed to levitte/openssl by levitte 3 years ago
- TEST: Add test specific fipsmodule.cnf, and use it We add the concept of preparation recipes, which are performed unconditionally. They are all expected to match the pattern test/recipes/00-prep_*.t... — committed to openssl/openssl by levitte 3 years ago
- Rework how providers/fipsmodule.cnf is produced First of all, we have concluded that we can calculate the integrity checksum with a simple perl script. Second, having the production of providers/fip... — committed to devnexen/openssl by levitte 3 years ago
- TEST: Add test specific fipsmodule.cnf, and use it We add the concept of preparation recipes, which are performed unconditionally. They are all expected to match the pattern test/recipes/00-prep_*.t... — committed to devnexen/openssl by levitte 3 years ago
The current wording and approach is a unnecessarily limiting and incomplete.
The user should be able to construct the configuration file in any manner than they wish on the target platform (i.e. we should not be requiring the existence of the openssl application and the ability to run a command line tool). What is necessary is that the mac has been calculated and stored - and that can be performed (the calculation) on any platform and that the self tests have been run on the target prior to first usage.
I would tend to create the configuration file as part of the build process without the self-tests-have-run indicator on the build platform. Updating the self-tests have run status is a separate exercise and the user should be able to perform that in any manner they wish - i.e. edit the file themselves manually etc - provided they are asserting that they have (somehow) run the self tests.
i.e. we should be decoupling this somewhat
The security policy document will have to provide the list of steps the installer of the module has to follow and they will necessarily have to allow for handling platforms where the installer won’t be running command line applications.
Remember that we have target platforms for the fips release where there is no command line and no shell available so it has to be possible to “install” and run on those platforms and what is there presently does not handle that context.
It takes roughly 1.8 seconds to run the self-tests in my 32-bit ARM environment. The optimization is absolutely necessary.
An aside: could we see how long the power up tests take to run? We might be able to avoid the optimisation entirely.
There are several flaws with the current approach in producing providers/fipsmodule.cnf. To begin with, only hooking that in the tests is flawed, considering that we depend on it for installation. That’s a bug.
Having the self tests always run on load on these targets seems like a reasonable thing to do (the tests are not slow). fipsinstall could also be run twice to generate 2 config files on the build system. The targets still need to run the self tests at least once though before using a config file that skips the self tests.
I accept that it is by design. However, it’s not clear to me how it will ever be possible for this design to support cross-compile environments where by definition you are building on one machine and executing on another. Furthermore, this design seems at odds with this blurb from README-FIPS.md:
I would think it’s a common use case to build on a central build server and then distribute the artifacts elsewhere. Attempting to also generate fipsmodule.cnf as part of that process goes contrary to the intent of that paragraph.
In view of my previous post: yes, this dependency is by design.