Bug 1959832
| Summary: | Upstream test suite fails when compiled with OpenSSL 3.0.0 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Alicja Kario <hkario> | ||||||
| Component: | openssl-pkcs11 | Assignee: | Jakub Jelen <jjelen> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Alicja Kario <hkario> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 9.0 | CC: | ansasaki, fweimer, jjelen, jorton, ksrot, sahana, szidek | ||||||
| Target Milestone: | beta | Keywords: | Triaged | ||||||
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | openssl-pkcs11-0.4.11-5.ssl3 | Doc Type: | No Doc Update | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2021-12-07 21:24:13 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1958021 | ||||||||
| Attachments: |
|
||||||||
|
Description
Alicja Kario
2021-05-12 13:04:05 UTC
First of all, the openssl-pkcs11 spec file has hardcoded path to engines-1.1, which should not be used with the new openssl. We need the new path with engines-3.
The only two failing tests are now these:
FAIL: rsa-testfork.softhsm
FAIL: ec-testfork.softhsm
These tests do not use engines (where everything works), but the libp11 API to handle the keys. The problem is that the new OpenSSL no longer respects the RSA->meth structure, which is part of the EVP_PKEY when requesting signature. The failure happens in crypto/evp/signature.c in function evp_pkey_signature_init(), which is called from the here:
#0 evp_pkey_signature_init (ctx=ctx@entry=0x4b6fb0, operation=operation@entry=16, params=params@entry=0x0)
at crypto/evp/signature.c:373
#1 0x00007ffff7d33a40 in EVP_PKEY_sign_init (ctx=ctx@entry=0x4b6fb0) at crypto/evp/signature.c:552
#2 0x00007ffff7d33aef in EVP_SignFinal_ex (ctx=ctx@entry=0x45b630, sigret=sigret@entry=0x45a870 "\nc@",
siglen=siglen@entry=0x7fffffffe11c, pkey=pkey@entry=0x457420, libctx=libctx@entry=0x0, propq=propq@entry=0x0)
at crypto/evp/p_sign.c:52
#3 0x00007ffff7d33c3f in EVP_SignFinal (ctx=ctx@entry=0x45b630, sigret=sigret@entry=0x45a870 "\nc@",
siglen=siglen@entry=0x7fffffffe11c, pkey=pkey@entry=0x457420) at crypto/evp/p_sign.c:68
#4 0x000000000040155f in main (argc=<optimized out>, argv=<optimized out>) at fork-test.c:230
The ctx->pmeth is NULL so this function does not know how to provide a signature:
(gdb) p ctx->pmeth
$6 = (const EVP_PKEY_METHOD *) 0x0
At this moment, we no longer have the original EVP_PKEY object, which contains our RSA object, but we still can find a "link" to that through the signature context, confirming the methods are set up correctly:
(gdb) p *ctx->pkey->pkey->rsa->meth
$5 = {name = 0x45a110 "libp11 RSA method", rsa_pub_enc = 0x7ffff7d7a550 <rsa_ossl_public_encrypt>,
rsa_pub_dec = 0x7ffff7d7b580 <rsa_ossl_public_decrypt>,
rsa_priv_enc = 0x7ffff7fb8a60 <pkcs11_rsa_priv_enc_method>,
rsa_priv_dec = 0x7ffff7fb89d0 <pkcs11_rsa_priv_dec_method>, rsa_mod_exp = 0x7ffff7d7ba30 <rsa_ossl_mod_exp>,
bn_mod_exp = 0x7ffff7c7e000 <BN_mod_exp_mont>, init = 0x7ffff7d72980 <rsa_ossl_init>,
finish = 0x7ffff7fb86a0 <pkcs11_rsa_free_method>, flags = 0, app_data = 0x0, rsa_sign = 0x0, rsa_verify = 0x0,
rsa_keygen = 0x0, rsa_multi_prime_keygen = 0x0}
Reading through this function, I do not think it can correctly provide a signature with the given context. EVP_PKEY_sign_init() is just wrapper around evp_pkey_signature_init() so nothing useful there.
In EVP_SignFinal_ex(), we can see that this is a place where the signing context is constructed (probably wrongly) through a function EVP_PKEY_CTX_new_from_pkey().
I filled the following OpenSSL issue with minimal reproducer:
https://github.com/openssl/openssl/issues/15350
I also submitted libp11 PR to fix this given that OpenSSL will not consider this (mis)use of API as important enough:
https://github.com/OpenSC/libp11/pull/406
AC: Verify the upstream testsuite passes when built OpenSSL 3.0 CentOS Stream MR: https://gitlab.com/redhat/centos-stream/rpms/openssl-pkcs11/-/merge_requests/2 Built with: koji -p stream build c9s-build-ssl3 'git+https://gitlab.com/redhat/centos-stream/rpms/openssl-pkcs11#c9s' Now, waiting for the brew and osci to pick up. The centos build: https://kojihub.stream.rdu2.redhat.com/koji/buildinfo?buildID=7678 The changes are in: http://pkgs.devel.redhat.com/cgit/rpms/openssl-pkcs11/commit/?h=rhel-9.0.0-beta but as we have the build only in side tag, the changes are not landing in compose. The changes will no longer work with openssl 1 (without too much of spec file patching) Sahana, are we supposed to build the changes in side tag also in brew or is it fine this way that it will pass the mass-rebuild? I am not sure if this can go into errata and if this can be verified like this. Are these changes in c9s dist-git? I still encounter a build failure. Created attachment 1800247 [details]
build.log
Yeah. The changes are in both centos and rhel dist gits and tested when they were submitted: https://gitlab.com/redhat/centos-stream/rpms/openssl-pkcs11/-/blob/c9s/openssl-pkcs11-0.4.10-openssl3.patch But it might be the case some new changes landed in openssl that broke this. Now, I see only ecc tests failing, which is different than last time: FAIL: ec-evp-sign.softhsm ========================= Current directory: /tmp/tmp.fingertipt/BUILD/libp11-0.4.11/tests Source directory: . Output directory: output.12120 * Initializing smart card... ok Using slot 0 with a present token (0x33c513d) error: Cannot parse key Aborting. FAIL ec-evp-sign.softhsm (exit status: 1) FAIL: ec-testfork.softhsm ========================= Current directory: /tmp/tmp.fingertipt/BUILD/libp11-0.4.11/tests Source directory: . Output directory: output.12152 * Initializing smart card... ok Using slot 0 with a present token (0x75cd6398) error: Cannot parse key Aborting. FAIL ec-testfork.softhsm (exit status: 1) FAIL: ec-check-privkey.softhsm ============================== Current directory: /tmp/tmp.fingertipt/BUILD/libp11-0.4.11/tests Source directory: . Output directory: output.12249 * Initializing smart card... ok Using slot 0 with a present token (0x34e6b9ca) error: Cannot parse key Aborting. FAIL ec-check-privkey.softhsm (exit status: 1) Jakub, should I open a new bug for the new failures? Or should we move this bug back to ASSIGNED (after adjusting DTM)? Please, open a new issue so we do not mess with the milestones. I hope I will get to that soon. This is an issue inside of OpenSC. The following code returns NULL pointer:
Breakpoint 2, parse_ec_pkey (gost=0x7fffffff9c70, private=1, pkey=0x555555606230) at /usr/src/debug/opensc-0.21.0-7.el9.x86_64/src/tools/pkcs11-tool.c:2912
2912 EC_KEY *src = EVP_PKEY_get0(pkey);
(gdb) p src
$6 = (EC_KEY *) 0x0
The pkey structure has the key type set, but not anything that would help figuring out the key itself:
(gdb) p *pkey
$7 = {type = 408, save_type = 0, ameth = 0x0, engine = 0x0, pmeth_engine = 0x0, pkey = {ptr = 0x0, rsa = 0x0, dsa = 0x0, dh = 0x0, ec = 0x0, ecx = 0x0}, legacy_cache_pkey = {ptr = 0x0, rsa = 0x0, dsa = 0x0, dh = 0x0, ec = 0x0,
ecx = 0x0}, references = 1, lock = 0x5555555a66d0, attributes = 0x0, save_parameters = 1, foreign = 0, ex_data = {ctx = 0x0, sk = 0x0}, keymgmt = 0x5555555f27b0, keydata = 0x55555567afd0, dirty_cnt = 0, operation_cache = 0x0,
dirty_cnt_copy = 0, cache = {bits = 256, security_bits = 128, size = 72}}
I filled the following openssl issue and hope I will have some update soon:
https://github.com/openssl/openssl/issues/16081
Created attachment 1804430 [details]
build.log for building against openssl-3.0.0-0.beta1.4.el9
Now, it looks like a new issue: # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: ec-check-privkey.softhsm The previous one was failing two different test and now only one fails. But looks like related to the following issue in libp11 upstream: https://github.com/OpenSC/libp11/issues/413 It is supposed to be fixed in openssl master, but probably not in beta yet: https://github.com/openssl/openssl/issues/15927 |