Add 2024 FIPS and fix build issues on older arm FIPS #1920
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issues:
P162016551
Description of changes:
Firstly, when building multiple versions of
bssl
using themain
branch as the base, builds on Arm will fail when using older versions of AWS-LC e.g. FIPS 2021 from the 2021 FIPS branch. The reason is that an internal header file[...]/cpucap/nternal.h
is included into the compilation unit by#include "..."
. The gcc search path will then, irrespective of any user-specified search paths via-I
, pick up themain
branch header files. This include identifiers such asARMV8_NEOVERSE_V2
. But the definition of this identifier is inarm_arch.h
, which is transitively included into the compilation unit via#include <..>
directives. The search path for these DO follow the user-specified search path from-I
(at least on GCC) and use e.g. the FIPS 2021 include file version ofarm_arch.h
that does not have the identifier defined. The result of this are build errors. For example, from one of the performance canary hosts:The pattern of adding internal header files to a consuming application that is going to be build with multiple old version of the library is not ideal, because one can hit these hidden incompatibilities that. But now it's a bit rusted-in and it's not apparent to me if there is a much easier way to organise it currently. Leaving that as an open question and simply fix by guarding the inclusion for now.
Secondly, the reason this even escaped as a bug, is that the CI doesn't test the special multiple-build of
bssl
with other library sources on Arm. We only test on x86_64. The above is purely an Arm-specific bug because for som reason there is a special Arm header file(?). I added an Arm stanza to the Arm omnibus config file that will execute the relevant test script.However, this needs to be deployed before taking effect.(EDIT: no, actually not...)Thirdly, the
LD_LIBRARY_PATH
option was incorrect foraws-lc-fips-2022
, when testing the executable. But, in fact, this doesn't actually matter forbssl
, becauseDT_RPATH
is set in the resulting executables, e.g.:When resolving the dynamic dependency at load-time,
DT_RPATH
takes precedence overLD_LIBRARY_PATH
. As an example, trying to resolve to another library version still resolve toDT_RPATH
from the executable:Finally, added the new FIPS 2024 prospective branch to the test cases.
Testing:
I tested the changes to the speed tool locally to ensure that build errors are resolved.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.