[3.0.3] Failed to load FIPS module using xlClang 16.1 compiler on AIX 7.2 #18435
Comments
t8m
added
triaged: question
|
My guess would be that the Default Entry Point code is failing with this compiler/platform: openssl/providers/fips/self_test.c Lines 77 to 156 in 6537beb Possibly it is falling through to the "This build does not support any kind of DEP" section, or possibly the pragmas in the AIX specific code are not operating as expected? |
|
Thanks Matt, I'll take a look at that. |
|
|
|
Is |
|
If not you can try to modify |
|
According to the 16.1 compiler docs, the |
Nope.
Tried this, produced this error on 32bit, similar to what we saw in #17087: Looks like xlclang has different macros though: I'll try it on 64bit to confirm if it works there and then modify the ifdef in crypto/bn/bn_ppc.c Edit: It doesn't work on 64bit either, fails with the original error again @makr Am I doing that wrong? Should I also remove the pragmas in [self_test.c]? openssl/providers/fips/self_test.c Lines 77 to 156 in 6537beb |
|
Hm ... the pragmas will probably just be ignored. The binder flag, however, might only be valid for linking shared objects. So it boils down to creating a |
|
I do see it on on this one line in the log for the original build I posted: This failed the tests though: |
|
Just noticed the 32bit plan using xlclang fails earlier than 64bit: I've only set |
|
With the 64-bit test failure I wonder if it is possible for you to run this in a debugger? It would be useful to set a breakpoint in the "init" function and see if it is ever hit. Or failing that just a "printf" in that function or similar. |
|
I'm not very familiar with the DBX debugger but I've heard it's a pain to use. |
There is a check for AIX at line 117 in that lot, so I doubt it's failing through. The way to check if the DEP is the problem is to force the code through the fallback on lines 152 - 155. If that makes things work, the DEP is at fault. If it doesn't we're probably looking in the wrong place. /*
* This is the Default Entry Point (DEP) code.
* See FIPS 140-2 IG 9.10
*/
/*
* This build does not support any kind of DEP.
* We force the self-tests to run as part of the FIPS provider initialisation
* rather than being triggered by the DEP.
*/
# undef DEP_INIT_ATTRIBUTE
# undef DEP_FINI_ATTRIBUTE
# undef DEP_INITIAL_STATE
# define DEP_INITIAL_STATE FIPS_STATE_SELFTESTbuild and try to run. |
|
Finally getting back to this.. Re-running that now to get you verbose logs... 32 bit still has this error from before: It's been a while since I looked at this but I thought we fixed that in another commit. |
|
Many of the test certificates we used expired recently. Updating the source tree should address those failures. |
|
Grabbed the 3.0.5 release and 64 bit built and passed unit tests! I don't have git installed so can't easily make a pull request, but I just updated two ifdefs in self_test.c so the new AIX compiler - xLClang - would hit the fallback. The older compiler - xLC - should be unaffected since Unfortunately, there appears to be a regression/refactor causing the 32bit build to fail. The old fix was made here: https://github.com/openssl/openssl/pull/17497/files Was it a breaking change? |
|
If you'd prefer to re-open #17087, please go ahead and close this after you've tried my code fix mentioned above. This 32bit build is the only one I need now to start using openssl 3.x across the board so let me know what your plans are here, if any. |
|
The bug that was fixed with #17497 was the build fix for XLC. These are irrelevant now as this code was completely dropped by the revert in 712d9cc For the __atomic_is_lock_free missing - could you please try to add |
|
Sorry, you're right. I did briefly mention this issue on that old ticket too but then completely forgot about it since we were only focusing on xLC at the time. Last time I was thinking that maybe we didn't have the necessary library installed/updated to contain this symbol but I'm not so sure now. It looks like there were some atomic functionality changes in xlclang: |
|
I am afraid this is some kind of problem with the xlclang frontend which should be discussed with IBM. I think adding |
|
I don't know our current support status with AIX so I'll have to ask around about that, thanks. I tried your suggestion and it does get a little further this time but there's another error: |
|
Unfortunately for that the only workaround would be to build with |
|
That allowed me to build it at least. We'll test performance and decide whether to use it or stick with 1.1.1 for AIX. Thanks for all the help :D |
Hey guys,
Seeing this problem when building with the xlclang frontend (to get C++11 support) but not when using the xlc frontend.
This frontend was only added with XLC 16.1 as far as I know so your testing may not cover it. It's not mentioned in your build template configurations either. More info on xlclang here: https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=new-clang-based-front-end
I'm overriding
CC,CXXandLDbefore invokingmaketo use the newer frontend.Config dump:
buildconfig.txt
As always, thanks in advance for your help :)
The text was updated successfully, but these errors were encountered: