Remove temporary allocation in mbedtls_mpi_sub_abs - single subtract implementation #373
No reviewers
Labels
No labels
api-spec
bug
CLA requested
CLA valid
compliance
DO NOT MERGE
duplicate
enhancement
feature branch
good first issue
HEADER FORMATTING ISSUE
help wanted
Information
invalid
Jira status: AWAITING REVIEW
Jira status: CLOSED
Jira status: DONE
Jira status: IN PROGRESS
Jira status: IN REVIEW
Jira status: OPEN
Jira status: REOPENED
Jira status: RESOLVED
mirrored
mirror internally
needs: backports
needs: ci
needs: design review
needs: preceding PR
needs: review
needs: work
notabug
open for community contribution
Product Backlog
question
ready for merge
security
stale
type: bug
type: enhancement
type: question
web pages
wontfix
writing
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-ARMmbed/mbed-crypto!373
Loading…
Reference in a new issue
No description provided.
Delete branch "single-subtract-implementation"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As requested in https://github.com/ARMmbed/mbed-crypto/pull/366 here's a new pull request that uses a single subtraction implementation.
Hi @marchmarch and sorry for keeping you waiting for so long, I'll finally have time to look seriously into this enhancement you're suggesting (thanks again for that!).
On the legal front, we'll need you to add a Signed-off-by tag to the first two commits in this PR as well, just as you did for the last one. (
git rebase -sshould do the trick with recent enough git)Regarding code size, I did some size measurements using
arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os -Iinclude -c library/bignum.c && arm-none-eabi-size bignum.oand here what I got:I also did some performance testing on my x86 machine, looking at the difference between development and this PR, and for FFDH and RSA the different was lower than the measurement noise, while for ECDH and ECDSA there was a measurable improvement.
So I would prefer the version in this PR to the one in #366 - which I understand was also Gilles's preference.
I'll review the code tomorrow.
@ -1328,23 +1328,42 @@ cleanup:}/*Makes sense. I updated the comment.
I added signed-off-by to the older commits.
Correction
Looks good to me apart from one minor issue.
Desirability
On a Cortex-M0+ build with
arm-gcc-none-eabi -Os(GCC 7.3.1),bignum.oincreases from 15885 bytes to 15909 bytes. This is a negligible increase.On my PC I see a performance gain (around +10%) with ECDSA/ECDH with P curves, and roughly stable performance otherwise (just with a quick run of the benchmark program).
So this pull request is a nice performance improvement.
@ -1328,23 +1328,42 @@ cleanup:}Even though it isn't necessary by C rules, we use the convention that
const mbedtls_mpi *Xmeans that the whole bignumXis not modified, i.e. we not only don't modifyX->some_fieldbut also we don't modifyX->p[some_index]either. Please declareXas non-const here.@ -1328,23 +1328,42 @@ cleanup:}I originally had the code that way but mpi_montmul/mpi_montred declare T as const so I get a warning if I don't make X const.
However, it looks like I can remove const from T in both mpi_montmul and mpi_montred without generating any compiler warnings. Is this OK with you?
@ -1328,23 +1328,42 @@ cleanup:}Yes, please do. I think it was a mistake to make
Tconst there.@ -1328,23 +1328,42 @@ cleanup:}OK, I removed const from those 3 functions.
Thanks for making the changes requested by Gilles. The result looks good to me.
Everything's passing in the CI except the mbed-os and IAR tests which are known issues independent from this PR.