fix minor bug in path_cnt checks #196
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the top certificate occurs twice in trust_ca (for example) it would not be good for the second instance to be checked with check_path_cnt reduced twice!
|
Thanks for catching this. I agree with your analysis. |
hanno-becker
pushed a commit
that referenced
this pull request
Nov 16, 2018
remove mbedtls_rsa_get_bitlen
gilles-peskine-arm
pushed a commit
to gilles-peskine-arm/mbedtls
that referenced
this pull request
Sep 3, 2019
Fix the license header of hkdf
gilles-peskine-arm
added a commit
to gilles-peskine-arm/mbedtls
that referenced
this pull request
Apr 16, 2021
Use bitwise or on the absolute values, rather than addition, to
combine a high-level error code with a low-level error code (or an
error code of either kind with 0). This gives the same result when
combining error codes of different levels, since those use disjoint
bit positions.
An advantage of using bitwise or is that it is more robust to
mistakes. For example, combining an error code with itself is now a
no-op. Combining two error codes from the same module is more likely
to result in an error code from that module. We detect such errors
dynamically in tests when MBEDTLS_TEST_HOOKS is enabled, but that
doesn't help for rare cases which are not covered by our tests.
Another advantage is that it guarantees that the result cannot be 0 if
either input is nonzero. This sometimes helps optimizers and static
analyzers.
A downside is that the generated code tends to be slightly larger. When
combining a high-level constant with a low-level value, which is a
common idiom, the typical cost with Arm Thumb seems to be 1 extra
instruction, e.g. dhm_read_bignum before:
30: 4b04 ldr r3, [pc, Mbed-TLS#16] ; (44 <dhm_read_bignum+0x44>)
32: 18c0 adds r0, r0, r3
44: ffffcf00 .word 0xffffcf00
After:
30: 23c4 movs r3, Mbed-TLS#196 ; 0xc4
32: 4240 negs r0, r0
34: 019b lsls r3, r3, Mbed-TLS#6
36: 4318 orrs r0, r3
38: 4240 negs r0, r0
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What do you think, is this a bug or not? I don't think it's dangerous, you'd need to have two CAs in the
trust_calist with the same subject name, but I think it counts as unintended behaviour that should be fixed.Noticed during code review.
Commit comment: If the top certificate occurs twice in trust_ca (for example) it would not be good for the second instance to be checked with check_path_cnt reduced twice!