Open qazsdcx opened 6 days ago
I'm not sure if the fault mitigation flow has been tested with a DRVCRYPT and software fallback. Looking at the code it seems that the FTMN_CALLEE_DONE(ret);
at the end of crypto_acipher_rsassa_verify()
in core/drivers/crypto/crypto_api/acipher/rsa.c
might interface with what's done in sw_crypto_cipher_rsasa_verify()
. Can you try with that line commented out?
It would be nice with a dummy DRVCRYPT implementation falling back to sw_crypto_cipher_rsasa_verify()
in QEMU to improve CI coverage.
I commented out FTMN_CALLEE_DONE(ret) in crypto_acipher_rsassa_verify() (core/drivers/crypto/crypto_api/acipher/rsa.c). It can run pass. Is this a work aound solution?
Thanks for confirming. No, it's not a good workaround. I'll try to come up with something.
Hi, experts
I am trying to replace the software encryption engine with a hardware encryption engine. I try to use core/drivers/crypto/crypto_api. I use drvcrypt_register_rsa to register rsa_init.
Then I plan to replace some RSA algorithms with hardware engines and implement the rest with software algorithms(libtomcrypto).
RSA verify function will be implemented by sw_crypto_acipher_rsassa_verify:
When I run CA to call TA. The sysytem halted. The log is as follows:
I founthe code shdr_verify_signature() in in signed_hdr.c
The return value of sw_crypto_cipher_rsasa_verify is 0, but there is an exception in FTMN_CALL_FUNC.
So how can I solve this problem?
BTW: My OP-TEE os version is 4.1.0
Thanks!