-
Notifications
You must be signed in to change notification settings - Fork 3
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
Rsa jerome #2
Rsa jerome #2
Conversation
Platform can overwrite the default 4096bit configuration to optimize memory space in OP-TEE core layer. Signed-off-by: Etienne Carriere <[email protected]>
The TEE Internal Core API provides generic APIs for TAs to manipulate ig numbers. This change increases the default value from 3072 to 4096 and allows platforms to optimize this value in case the TAs are expected to execute in small memory and should lower their memory footprint. Signed-off-by: Etienne Carriere <[email protected]>
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.
LGTM with a few comments.
Also please fix the typo in the 2nd commit message s/ig/big/
.
Then Reviewed-by: Jerome Forissier <[email protected]>
and I will cherry-pick your commits in my optee_os
PR. Thanks :)
@@ -493,7 +493,7 @@ TEE_Result crypto_hash_final(void *ctx, uint32_t algo, uint8_t *digest, | |||
|
|||
#if defined(_CFG_CRYPTO_WITH_ACIPHER) | |||
|
|||
#define LTC_MAX_BITS_PER_VARIABLE (4096) | |||
#define LTC_MAX_BITS_PER_VARIABLE CFG_CORE_BIGNUM_MAX_BITS |
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.
Since LTC_MAX_BITS_PER_VARIABLE
is used only in this file, it's better to s/LTC_MAX_BITS_PER_VARIABLE/CFG_CORE_BIGNUM_MAX_BITS/
in the whole file.
# Define the max bit size for big number representation in TEE priviledge | ||
# layer. 4096 is currently the max supported by the underlying crypto library. | ||
# TEEs running in constrained sized memory may want to optimize this value. | ||
CFG_CORE_BIGNUM_MAX_BITS ?= 4096 |
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.
- s/priviledge/privileged/
- The crypto library (LibTomCrypt) is a user of the big numbers library, so it is not really "underlying", it is the opposite. The key sizes are limited by the bignum size.
How about:
# Define the maximum size, in bits, for big numbers in the TEE core (privileged layer).
# This value is an upper limit for the key size in any cryptographic algorithm
# implemented by the TEE core.
# Set this to a lower value to reduce the memory footprint.
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.
thanks for the suggestion, I agree with your proposal.
@@ -73,7 +73,7 @@ | |||
* It defines the size of the scratch memory pool for the underlying | |||
* mpa library. | |||
*/ | |||
#define TEE_MAX_NUMBER_OF_SUPPORTED_BITS 2048 | |||
#define TEE_MAX_NUMBER_OF_SUPPORTED_BITS CFG_TA_BIGNUM_MAX_BITS |
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.
Here too I think we should not bother with two names for the same thing => s/TEE_MAX_NUMBER_OF_SUPPORTED_BITS/CFG_TA_BIGNUM_MAX_BITS/
.
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 agree with all your comment. I can update my post.
But frankly, wouldn't it be easier for you if you take the ownership of the changes ? rather than I updating it as review progresses. I really don't mind you removing my S-o-b and put yours instead. The content is obviously not of my sole contribution but already from shared inputs from jens' feedback and yours.
# Define the max bit size for big number representation in TEE priviledge | ||
# layer. 4096 is currently the max supported by the underlying crypto library. | ||
# TEEs running in constrained sized memory may want to optimize this value. | ||
CFG_CORE_BIGNUM_MAX_BITS ?= 4096 |
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.
thanks for the suggestion, I agree with your proposal.
OK, I will rework my original PR to add similar changes. Thanks. |
This commit introduces an algorithm that may be used to detect improper usage of locks at runtime. It can detect two kinds errors: 1. A thread tries to release a lock it does not own, 2. A thread tries to aquire a lock and the operation could *potentially* result in a deadlock. The potential deadlock detection assumes that the code adheres to a strict locking hierarchy, in other word, that there is a partial ordering on the locks so that there can be no situation where circular waits can occur. To put things simply, any two locks should be acquired in the same order in the same thread. This addresses the following case: [Thread #1] [Thread #2] lock(A) lock(B) lock(B) lock(A) <-- deadlock! ... The algorithm builds the lock hierarchy dynamically and reports as soon as a violation is detected. The interface is made of two functions: lockdep_lock_acquire() and lockdep_lock_release(), which are meant to be introduced in the implementation of the actual lock objects. The "acquire" hook tells the algorithm that a particular lock is about to be requested by a particular thread, while the "release" hook is meant to be called before the lock is actually released. If an error is detected, debugging information is sent to the console, and panic() is called. The debugging information includes the lock cycle that was detected (in the above example, {A, B}), as well as the call stacks at the points where the locks were acquired. The good thing with such an instrumentation of the locking code is that there is no need to wait for an actual deadlock to occur in order to detect potential problems. For instance, the timing of execution in the above example could be different but the problem would still be detected: [Thread #1] [Thread #2] lock(A) lock(B) unlock(B) unlock(A) lock(B) lock(A) <-- error! A pseudo-TA is added for testing (pta/core_lockdep_tests.c). This code is based on two sources: - A presentation called "Dl-Check: dynamic potential deadlock detection tool for Java programs" [1], although the somewhat complex MNR algorithm for topological ordering of a DAG was not used; - A depth-first search algorithm [2] was used instead. Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search Signed-off-by: Jerome Forissier <[email protected]>
This commit introduces an algorithm that may be used to detect improper usage of locks at runtime. It can detect two kinds errors: 1. A thread tries to release a lock it does not own, 2. A thread tries to aquire a lock and the operation could *potentially* result in a deadlock. The potential deadlock detection assumes that the code adheres to a strict locking hierarchy, in other word, that there is a partial ordering on the locks so that there can be no situation where circular waits can occur. To put things simply, any two locks should be acquired in the same order in the same thread. This addresses the following case: [Thread #1] [Thread #2] lock(A) lock(B) lock(B) lock(A) <-- deadlock! ... The algorithm builds the lock hierarchy dynamically and reports as soon as a violation is detected. The interface is made of two functions: lockdep_lock_acquire() and lockdep_lock_release(), which are meant to be introduced in the implementation of the actual lock objects. The "acquire" hook tells the algorithm that a particular lock is about to be requested by a particular thread, while the "release" hook is meant to be called before the lock is actually released. If an error is detected, debugging information is sent to the console, and panic() is called. The debugging information includes the lock cycle that was detected (in the above example, {A, B}), as well as the call stacks at the points where the locks were acquired. The good thing with such an instrumentation of the locking code is that there is no need to wait for an actual deadlock to occur in order to detect potential problems. For instance, the timing of execution in the above example could be different but the problem would still be detected: [Thread #1] [Thread #2] lock(A) lock(B) unlock(B) unlock(A) lock(B) lock(A) <-- error! A pseudo-TA is added for testing (pta/core_lockdep_tests.c). This code is based on two sources: - A presentation called "Dl-Check: dynamic potential deadlock detection tool for Java programs" [1], although the somewhat complex MNR algorithm for topological ordering of a DAG was not used; - A depth-first search algorithm [2] was used instead. Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search Signed-off-by: Jerome Forissier <[email protected]>
This commit introduces an algorithm that may be used to detect improper usage of locks at runtime. It can detect two kinds errors: 1. A thread tries to release a lock it does not own, 2. A thread tries to aquire a lock and the operation could *potentially* result in a deadlock. The potential deadlock detection assumes that the code adheres to a strict locking hierarchy, in other word, that there is a partial ordering on the locks so that there can be no situation where circular waits can occur. To put things simply, any two locks should be acquired in the same order in the same thread. This addresses the following case: [Thread #1] [Thread #2] lock(A) lock(B) lock(B) lock(A) <-- deadlock! ... The algorithm builds the lock hierarchy dynamically and reports as soon as a violation is detected. The interface is made of two functions: lockdep_lock_acquire() and lockdep_lock_release(), which are meant to be introduced in the implementation of the actual lock objects. The "acquire" hook tells the algorithm that a particular lock is about to be requested by a particular thread, while the "release" hook is meant to be called before the lock is actually released. If an error is detected, debugging information is sent to the console, and panic() is called. The debugging information includes the lock cycle that was detected (in the above example, {A, B}), as well as the call stacks at the points where the locks were acquired. The good thing with such an instrumentation of the locking code is that there is no need to wait for an actual deadlock to occur in order to detect potential problems. For instance, the timing of execution in the above example could be different but the problem would still be detected: [Thread #1] [Thread #2] lock(A) lock(B) unlock(B) unlock(A) lock(B) lock(A) <-- error! A pseudo-TA is added for testing (pta/core_lockdep_tests.c). This code is based on two sources: - A presentation called "Dl-Check: dynamic potential deadlock detection tool for Java programs" [1], although the somewhat complex MNR algorithm for topological ordering of a DAG was not used; - A depth-first search algorithm [2] was used instead. Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search Signed-off-by: Jerome Forissier <[email protected]>
This commit introduces an algorithm that may be used to detect improper usage of locks at runtime. It can detect two kinds errors: 1. A thread tries to release a lock it does not own, 2. A thread tries to aquire a lock and the operation could *potentially* result in a deadlock. The potential deadlock detection assumes that the code adheres to a strict locking hierarchy, in other word, that there is a partial ordering on the locks so that there can be no situation where circular waits can occur. To put things simply, any two locks should be acquired in the same order in the same thread. This addresses the following case: [Thread #1] [Thread #2] lock(A) lock(B) lock(B) lock(A) <-- deadlock! ... The algorithm builds the lock hierarchy dynamically and reports as soon as a violation is detected. The interface is made of two functions: lockdep_lock_acquire() and lockdep_lock_release(), which are meant to be introduced in the implementation of the actual lock objects. The "acquire" hook tells the algorithm that a particular lock is about to be requested by a particular thread, while the "release" hook is meant to be called before the lock is actually released. If an error is detected, debugging information is sent to the console, and panic() is called. The debugging information includes the lock cycle that was detected (in the above example, {A, B}), as well as the call stacks at the points where the locks were acquired. The good thing with such an instrumentation of the locking code is that there is no need to wait for an actual deadlock to occur in order to detect potential problems. For instance, the timing of execution in the above example could be different but the problem would still be detected: [Thread #1] [Thread #2] lock(A) lock(B) unlock(B) unlock(A) lock(B) lock(A) <-- error! A pseudo-TA is added for testing (pta/core_lockdep_tests.c). This code is based on two sources: - A presentation called "Dl-Check: dynamic potential deadlock detection tool for Java programs" [1], although the somewhat complex MNR algorithm for topological ordering of a DAG was not used; - A depth-first search algorithm [2] was used instead. Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search Signed-off-by: Jerome Forissier <[email protected]>
This commit introduces an algorithm that may be used to detect improper usage of locks at runtime. It can detect two kinds errors: 1. A thread tries to release a lock it does not own, 2. A thread tries to aquire a lock and the operation could *potentially* result in a deadlock. The potential deadlock detection assumes that the code adheres to a strict locking hierarchy, in other word, that there is a partial ordering on the locks so that there can be no situation where circular waits can occur. To put things simply, any two locks should be acquired in the same order in the same thread. This addresses the following case: [Thread #1] [Thread #2] lock(A) lock(B) lock(B) lock(A) <-- deadlock! ... The algorithm builds the lock hierarchy dynamically and reports as soon as a violation is detected. The interface is made of two functions: lockdep_lock_acquire() and lockdep_lock_release(), which are meant to be introduced in the implementation of the actual lock objects. The "acquire" hook tells the algorithm that a particular lock is about to be requested by a particular thread, while the "release" hook is meant to be called before the lock is actually released. If an error is detected, debugging information is sent to the console, and panic() is called. The debugging information includes the lock cycle that was detected (in the above example, {A, B}), as well as the call stacks at the points where the locks were acquired. The good thing with such an instrumentation of the locking code is that there is no need to wait for an actual deadlock to occur in order to detect potential problems. For instance, the timing of execution in the above example could be different but the problem would still be detected: [Thread #1] [Thread #2] lock(A) lock(B) unlock(B) unlock(A) lock(B) lock(A) <-- error! A pseudo-TA is added for testing (pta/core_lockdep_tests.c). This code is based on two sources: - A presentation called "Dl-Check: dynamic potential deadlock detection tool for Java programs" [1], although the somewhat complex MNR algorithm for topological ordering of a DAG was not used; - A depth-first search algorithm [2] was used instead. Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search Signed-off-by: Jerome Forissier <[email protected]>
This commit introduces an algorithm that may be used to detect improper usage of locks at runtime. It can detect two kinds errors: 1. A thread tries to release a lock it does not own, 2. A thread tries to aquire a lock and the operation could *potentially* result in a deadlock. The potential deadlock detection assumes that the code adheres to a strict locking hierarchy, in other word, that there is a partial ordering on the locks so that there can be no situation where circular waits can occur. To put things simply, any two locks should be acquired in the same order in the same thread. This addresses the following case: [Thread #1] [Thread #2] lock(A) lock(B) lock(B) lock(A) <-- deadlock! ... The algorithm builds the lock hierarchy dynamically and reports as soon as a violation is detected. The interface is made of two functions: lockdep_lock_acquire() and lockdep_lock_release(), which are meant to be introduced in the implementation of the actual lock objects. The "acquire" hook tells the algorithm that a particular lock is about to be requested by a particular thread, while the "release" hook is meant to be called before the lock is actually released. If an error is detected, debugging information is sent to the console, and panic() is called. The debugging information includes the lock cycle that was detected (in the above example, {A, B}), as well as the call stacks at the points where the locks were acquired. The good thing with such an instrumentation of the locking code is that there is no need to wait for an actual deadlock to occur in order to detect potential problems. For instance, the timing of execution in the above example could be different but the problem would still be detected: [Thread #1] [Thread #2] lock(A) lock(B) unlock(B) unlock(A) lock(B) lock(A) <-- error! A pseudo-TA is added for testing (pta/core_lockdep_tests.c). This code is based on two sources: - A presentation called "Dl-Check: dynamic potential deadlock detection tool for Java programs" [1], although the somewhat complex MNR algorithm for topological ordering of a DAG was not used; - A depth-first search algorithm [2] was used instead. Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search Signed-off-by: Jerome Forissier <[email protected]>
This commit introduces an algorithm that may be used to detect improper usage of locks at runtime. It can detect two kinds errors: 1. A thread tries to release a lock it does not own, 2. A thread tries to aquire a lock and the operation could *potentially* result in a deadlock. The potential deadlock detection assumes that the code adheres to a strict locking hierarchy, in other word, that there is a partial ordering on the locks so that there can be no situation where circular waits can occur. To put things simply, any two locks should be acquired in the same order in the same thread. This addresses the following case: [Thread #1] [Thread #2] lock(A) lock(B) lock(B) lock(A) <-- deadlock! ... The algorithm builds the lock hierarchy dynamically and reports as soon as a violation is detected. The interface is made of two functions: lockdep_lock_acquire() and lockdep_lock_release(), which are meant to be introduced in the implementation of the actual lock objects. The "acquire" hook tells the algorithm that a particular lock is about to be requested by a particular thread, while the "release" hook is meant to be called before the lock is actually released. If an error is detected, debugging information is sent to the console, and panic() is called. The debugging information includes the lock cycle that was detected (in the above example, {A, B}), as well as the call stacks at the points where the locks were acquired. The good thing with such an instrumentation of the locking code is that there is no need to wait for an actual deadlock to occur in order to detect potential problems. For instance, the timing of execution in the above example could be different but the problem would still be detected: [Thread #1] [Thread #2] lock(A) lock(B) unlock(B) unlock(A) lock(B) lock(A) <-- error! A pseudo-TA is added for testing (pta/core_lockdep_tests.c). This code is based on two sources: - A presentation called "Dl-Check: dynamic potential deadlock detection tool for Java programs" [1], although the somewhat complex MNR algorithm for topological ordering of a DAG was not used; - A depth-first search algorithm [2] was used instead. Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Joakim Bech <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>
This commit introduces an algorithm that may be used to detect improper usage of locks at runtime. It can detect two kinds errors: 1. A thread tries to release a lock it does not own, 2. A thread tries to aquire a lock and the operation could *potentially* result in a deadlock. The potential deadlock detection assumes that the code adheres to a strict locking hierarchy, in other word, that there is a partial ordering on the locks so that there can be no situation where circular waits can occur. To put things simply, any two locks should be acquired in the same order in the same thread. This addresses the following case: [Thread #1] [Thread #2] lock(A) lock(B) lock(B) lock(A) <-- deadlock! ... The algorithm builds the lock hierarchy dynamically and reports as soon as a violation is detected. The interface is made of two functions: lockdep_lock_acquire() and lockdep_lock_release(), which are meant to be introduced in the implementation of the actual lock objects. The "acquire" hook tells the algorithm that a particular lock is about to be requested by a particular thread, while the "release" hook is meant to be called before the lock is actually released. If an error is detected, debugging information is sent to the console, and panic() is called. The debugging information includes the lock cycle that was detected (in the above example, {A, B}), as well as the call stacks at the points where the locks were acquired. The good thing with such an instrumentation of the locking code is that there is no need to wait for an actual deadlock to occur in order to detect potential problems. For instance, the timing of execution in the above example could be different but the problem would still be detected: [Thread #1] [Thread #2] lock(A) lock(B) unlock(B) unlock(A) lock(B) lock(A) <-- error! A pseudo-TA is added for testing (pta/core_lockdep_tests.c). This code is based on two sources: - A presentation called "Dl-Check: dynamic potential deadlock detection tool for Java programs" [1], although the somewhat complex MNR algorithm for topological ordering of a DAG was not used; - A depth-first search algorithm [2] was used instead. Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Joakim Bech <[email protected]> Reviewed-by: Etienne Carriere <[email protected]> Acked-by: Jens Wiklander <[email protected]>
This commit introduces an algorithm that may be used to detect improper usage of locks at runtime. It can detect two kinds errors: 1. A thread tries to release a lock it does not own, 2. A thread tries to aquire a lock and the operation could *potentially* result in a deadlock. The potential deadlock detection assumes that the code adheres to a strict locking hierarchy, in other word, that there is a partial ordering on the locks so that there can be no situation where circular waits can occur. To put things simply, any two locks should be acquired in the same order in the same thread. This addresses the following case: [Thread #1] [Thread #2] lock(A) lock(B) lock(B) lock(A) <-- deadlock! ... The algorithm builds the lock hierarchy dynamically and reports as soon as a violation is detected. The interface is made of two functions: lockdep_lock_acquire() and lockdep_lock_release(), which are meant to be introduced in the implementation of the actual lock objects. The "acquire" hook tells the algorithm that a particular lock is about to be requested by a particular thread, while the "release" hook is meant to be called before the lock is actually released. If an error is detected, debugging information is sent to the console, and panic() is called. The debugging information includes the lock cycle that was detected (in the above example, {A, B}), as well as the call stacks at the points where the locks were acquired. The good thing with such an instrumentation of the locking code is that there is no need to wait for an actual deadlock to occur in order to detect potential problems. For instance, the timing of execution in the above example could be different but the problem would still be detected: [Thread #1] [Thread #2] lock(A) lock(B) unlock(B) unlock(A) lock(B) lock(A) <-- error! A pseudo-TA is added for testing (pta/core_lockdep_tests.c). This code is based on two sources: - A presentation called "Dl-Check: dynamic potential deadlock detection tool for Java programs" [1], although the somewhat complex MNR algorithm for topological ordering of a DAG was not used; - A depth-first search algorithm [2] was used instead. Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Joakim Bech <[email protected]> Reviewed-by: Etienne Carriere <[email protected]> Acked-by: Jens Wiklander <[email protected]>
Tracing the log syscall is of very little value since it will generate some output to the console anyways. Worse, it pollutes the TA output in case of a panic or an abort. For example: o regression_4005.1 AE case 0 algo 0x40000710 line 2819 F/TC:?? 0 trace_syscall:132 syscall OP-TEE#27 (syscall_cryp_obj_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#15 (syscall_cryp_state_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#27 (syscall_cryp_obj_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#30 (syscall_cryp_obj_populate) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#29 (syscall_cryp_obj_reset) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#31 (syscall_cryp_obj_copy) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#28 (syscall_cryp_obj_close) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#34 (syscall_authenc_init) F/TC:?? 0 trace_syscall:132 syscall #2 (syscall_panic) E/TC:?? 0 E/TC:?? 0 TA panicked with code 0xffff0006 F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: Status of TA cb3e5ba0-adf1-11e0-998b-0002a5d5c51b F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: arch: aarch64 F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: region 0: va 0x40004000 pa 0x100062d000 size 0x002000 flags rw-s (ldelf) F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: region 1: va 0x40006000 pa 0x100062f000 size 0x00d000 flags r-xs (ldelf) ... Therefore, skip the trace if the syscall number it TEE_SCN_LOG. Signed-off-by: Jerome Forissier <[email protected]>
Tracing the log syscall is of very little value since it will generate some output to the console anyways. Worse, it pollutes the TA output in case of a panic or an abort. For example: o regression_4005.1 AE case 0 algo 0x40000710 line 2819 F/TC:?? 0 trace_syscall:132 syscall OP-TEE#27 (syscall_cryp_obj_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#15 (syscall_cryp_state_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#27 (syscall_cryp_obj_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#30 (syscall_cryp_obj_populate) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#29 (syscall_cryp_obj_reset) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#31 (syscall_cryp_obj_copy) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#28 (syscall_cryp_obj_close) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#34 (syscall_authenc_init) F/TC:?? 0 trace_syscall:132 syscall #2 (syscall_panic) E/TC:?? 0 E/TC:?? 0 TA panicked with code 0xffff0006 F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: Status of TA cb3e5ba0-adf1-11e0-998b-0002a5d5c51b F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: arch: aarch64 F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: region 0: va 0x40004000 pa 0x100062d000 size 0x002000 flags rw-s (ldelf) F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: region 1: va 0x40006000 pa 0x100062f000 size 0x00d000 flags r-xs (ldelf) ... Therefore, skip the trace if the syscall number it TEE_SCN_LOG. Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
Tracing the log syscall is of very little value since it will generate some output to the console anyways. Worse, it pollutes the TA output in case of a panic or an abort. For example: o regression_4005.1 AE case 0 algo 0x40000710 line 2819 F/TC:?? 0 trace_syscall:132 syscall OP-TEE#27 (syscall_cryp_obj_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#15 (syscall_cryp_state_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#27 (syscall_cryp_obj_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#30 (syscall_cryp_obj_populate) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#29 (syscall_cryp_obj_reset) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#31 (syscall_cryp_obj_copy) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#28 (syscall_cryp_obj_close) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#34 (syscall_authenc_init) F/TC:?? 0 trace_syscall:132 syscall #2 (syscall_panic) E/TC:?? 0 E/TC:?? 0 TA panicked with code 0xffff0006 F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: Status of TA cb3e5ba0-adf1-11e0-998b-0002a5d5c51b F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: arch: aarch64 F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: region 0: va 0x40004000 pa 0x100062d000 size 0x002000 flags rw-s (ldelf) F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: region 1: va 0x40006000 pa 0x100062f000 size 0x00d000 flags r-xs (ldelf) ... Therefore, skip the trace if the syscall number it TEE_SCN_LOG. Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
Adds checks in e32_relocate() that sym_tab is assigned a symbol table before using it. This fixes coverity scan: CID 1501826 (#1 of 3): Explicit null dereferenced (FORWARD_NULL) CID 1501826 (#2 of 3): Explicit null dereferenced (FORWARD_NULL) CID 1501826 (#3 of 3): Explicit null dereferenced (FORWARD_NULL) Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
No description provided.