Skip to content

Conversation

@Jakuje
Copy link
Member

@Jakuje Jakuje commented Apr 21, 2023

Closes #2736

The leaks in valgrind are not yet "enforced" with --error-exitcode=1 as it fails at several occasions that need to be fixed.

Checklist
  • PKCS#11 module is tested
  • Windows minidriver is tested
  • macOS tokend is tested

@Jakuje Jakuje force-pushed the valgrind-ci branch 3 times, most recently from 648b958 to 5069f98 Compare April 24, 2023 18:38
@Jakuje Jakuje force-pushed the valgrind-ci branch 2 times, most recently from a9e02ad to fb2f07e Compare May 4, 2023 16:34
Jakuje added 5 commits May 18, 2023 13:03
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.
@Jakuje Jakuje force-pushed the valgrind-ci branch 3 times, most recently from 6f2bde4 to d2fa3b2 Compare May 18, 2023 19:05
Jakuje added 13 commits May 19, 2023 10:34
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
@Jakuje Jakuje requested a review from frankmorgner May 19, 2023 15:13
@Jakuje
Copy link
Member Author

Jakuje commented May 19, 2023

This is getting to be ready for reviews. Now, valgrind is executed over the emulator tests as well as make check unit tests or shell tests, which surfaced several issues including reproducing the issue reported in #2775.

@frankmorgner can you have a look?

@swissbit-csteuer Can you have a look that the fixes for the isoapplet make sense?

I plan to remove the suppression file as there is nothing to suppress now (when we got rid of the pcsclite issues and issues brought in by glib/gobject/notifications), there will likely be some more issues from the isoapplet/openpgp, but I think this should be close to final version.

Jakuje added 3 commits May 19, 2023 17:55
…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.
@Jakuje Jakuje force-pushed the valgrind-ci branch 3 times, most recently from dd1f634 to d5e5c24 Compare May 19, 2023 19:22
Jakuje added 3 commits May 19, 2023 21:59
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);
Copy link
Contributor

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.

Copy link
Member Author

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).

Copy link
Member

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.

Copy link
Member Author

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?

Comment on lines -1221 to +1227
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);
}
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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?

Copy link
Member Author

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 ...

Copy link
Contributor

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 👍

Copy link
Member

@frankmorgner frankmorgner left a 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);
Copy link
Member

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.

@Jakuje
Copy link
Member Author

Jakuje commented May 31, 2023

@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?

@frankmorgner
Copy link
Member

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!

@Jakuje
Copy link
Member Author

Jakuje commented May 31, 2023

Thank you for the reviews! Merging. The new issue is #2790

@Jakuje Jakuje mentioned this pull request May 31, 2023
5 tasks
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;
Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in #2791

@xhanulik xhanulik mentioned this pull request Jul 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Integrate valgrind into CI tests

4 participants