-
Notifications
You must be signed in to change notification settings - Fork 803
Run tests also under valgrind #2756
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
648b958 to
5069f98
Compare
a9e02ad to
fb2f07e
Compare
This is useful for running the CI locally in containers, which makes things much faster than it would need to download, build and install all the test tools.
6f2bde4 to
d2fa3b2
Compare
There were needless assignment immediately rewritten with copy function, some of the structures were not copied and not freed from the target contexts and similar issues.
Reported by clang-tidy as set-but never read variable:
/home/runner/work/OpenSC/OpenSC/src/libopensc/iso7816.c:366:2: warning: Value stored to 'r' is never read [clang-analyzer-deadcode.DeadStores]
r = count;
^
/home/runner/work/OpenSC/OpenSC/src/libopensc/iso7816.c:366:2: note: Value stored to 'r' is never read
Accidentally introduced with 264b23a, reported by clang-tidy /home/runner/work/OpenSC/OpenSC/src/libopensc/card-westcos.c:664:7: warning: Although the value stored to 'cctx' is used in the enclosing expression, the value is never actually read from 'cctx' [clang-analyzer-deadcode.DeadStores] if ((cctx = EVP_CIPHER_CTX_new()) == NULL) ^ /home/runner/work/OpenSC/OpenSC/src/libopensc/card-westcos.c:664:7: note: Although the value stored to 'cctx' is used in the enclosing expression, the value is never actually read from 'cctx'
Reported by clang-tidy:
/home/runner/work/OpenSC/OpenSC/src/libopensc/card-sc-hsm.c:854:3: warning: Value stored to 'len' is never read [clang-analyzer-deadcode.DeadStores]
len = 0;
^
/home/runner/work/OpenSC/OpenSC/src/libopensc/card-sc-hsm.c:854:3: note: Value stored to 'len' is never read
|
This is getting to be ready for reviews. Now, valgrind is executed over the emulator tests as well as @frankmorgner can you have a look? @swissbit-csteuer Can you have a look that the fixes for the isoapplet make sense?
|
…estinfo This lead to using of uninitialized memory (tmp array) when talking to the pcsc and inevitable failure to verify the signature throughout the tests.
dd1f634 to
d5e5c24
Compare
both tests executed during `make check` as well as the integration tests ran from the github CI with java card simulator or other software implementations.
| memcpy(pubkey->u.ec.ecpointQ.value, args.pubkey.ec.ecPointQ.value, args.pubkey.ec.ecPointQ.len); | ||
|
|
||
| /* The OID is also written to the pubkey->u.ec.params */ | ||
| free(pubkey->u.ec.params.der.value); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't that dangerous? We don't know where pubkey->u.ec.params.der.value points to and who "owns" it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would help if this would be a bit more described. In the past, the EC params were sometimes very wildly assigned to various structures without much care. I hope this has improved a bit over last year with the fuzzing and with this PR.
For this case, the pubkey comes from sc_pkcs15init_generate_key() function, where it is memset to zeroes and then the EC params are copied to that structure from the keygen params using sc_copy_ec_params() so it should not really be anything dangerous (unless somebody starts assigning here some dangerous values on the way).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the ec->params, we need to get a common understanding about memory owner ship and proper initialization/cleanup this is ture. But I'd like to postpone this for now to move on with all the good stuff in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I drop some of the patches/changes from the PR to get it merged (without these changes, the CI will most likely fail)? Or do you mean that we should just create a follow-up issue to review how the ec->params are handled in various cases?
| sc_pkcs1_strip_digest_info_prefix(NULL, data, datalen, tmp, &tmplen); | ||
| r = iso_ops->compute_signature(card, tmp, tmplen, out, outlen); | ||
| r = sc_pkcs1_strip_digest_info_prefix(NULL, data, datalen, tmp, &tmplen); | ||
| if (r == SC_SUCCESS) { | ||
| r = iso_ops->compute_signature(card, tmp, tmplen, out, outlen); | ||
| } else { | ||
| /* No digest info present? Use the value as it is */ | ||
| r = iso_ops->compute_signature(card, data, datalen, out, outlen); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think its better to return an error if the digest info is missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no digestinfo in case the RSA_PKCS_PSS mechanism is used (as visible in the modified p11test results). If you use the SHA*_RSA_PKCS_PSS mechanism, the input is either hashed inside of the card or in OpenSC, depending on the card capabilities, but with RSA_PKCS_PSS, the OpenSC gets the digest only with the length of hLen so there is no digestinfo involved (the digest is part of the PSS_PARAMS structure though):
https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/os/pkcs11-curr-v3.0-os.html#_Toc30061139
At least that is how I covered this mechanism in the p11test and how it works with other cards so far. If you reading of the specs is different, feel free to correct me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm reading the spec the same way, but I still do not understand how this has worked before where the return code of sc_pkcs1_strip_digest_info_prefix was not checked. Shouldn't the RSA_PKCS_PSS test cases in p11test have failed before that change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they were failing, but given the vast amount of the combination for the RSA-PSS and that really no driver supports everything, the failures are silently ignored ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood. Forwarding the data as-is to the card if no digest is present is the correct way then 👍
The valgrind macros set the VALGRIND variable without any arguments, which prevents it from failing if some issue is detected.
frankmorgner
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This pull request is great work, thank you!
| memcpy(pubkey->u.ec.ecpointQ.value, args.pubkey.ec.ecPointQ.value, args.pubkey.ec.ecPointQ.len); | ||
|
|
||
| /* The OID is also written to the pubkey->u.ec.params */ | ||
| free(pubkey->u.ec.params.der.value); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the ec->params, we need to get a common understanding about memory owner ship and proper initialization/cleanup this is ture. But I'd like to postpone this for now to move on with all the good stuff in this PR.
|
@frankmorgner can you clarify what you mean with the "good stuff" so we can move on with this? I see approvals but also some concerns in your last comment. Or should I merge it and open a follow-up issue to review the EC parameters ownership throughout the code? |
Yes, that's what I wanted to say. thank you! |
|
Thank you for the reviews! Merging. The new issue is #2790 |
| r = SC_ERROR_OUT_OF_MEMORY; | ||
| LOG_TEST_GOTO_ERR(ctx, r, "Cannot allocate EC params"); | ||
| } | ||
| key.u.ec.ecpointQ.len = key.u.ec.ecpointQ.len; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CID 385152: Incorrect expression (NO_EFFECT)
Assigning "key.u.ec.ecpointQ.len" to itself has no effect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in #2791
Closes #2736
The leaks in valgrind are not yet "enforced" with--error-exitcode=1as it fails at several occasions that need to be fixed.Checklist