Fix #5079. Support of call to mbedtls_x_finish without calling mbedtls_x_update #5630

adustm · 2017-12-01T10:31:10Z

Description

Fix #5079
Support of call to mbedtls_x_finish without calling mbedtls_x_update.

Status

READY
Before the PR: failure occurs in case of an empty input and mbedtls_xx_update is not called between xxx_start and xxx_finish

After this PR:

SHA1 / SHA256 / MD5 hardware acceleration is activated for STM32F439xI
An empty input can be encrypted correctly even is the call to mbedtls_xxx_update has been omited

~~[] To do: test MD5, as it is not compiled in mbed-os (I could not find a way to activate it, can someone help me for this ?)~~ [edit 12.14.2017 -> MD5 link issue is now fixed.]

Steps to test or reproduce

Use the test available in #5079

ciarmcom · 2017-12-01T13:42:41Z

ARM Internal Ref: IOTSSL-1930

adustm · 2017-12-12T16:33:13Z

Hello @andresag01
Do you have any feedback for this bug fix ?
Kind regards
Armelle

andresag01 · 2017-12-12T21:29:55Z

Hi @adustm, thanks for the fix! I have not done a thorough review, but after a quick look the changes look good. However, @mazimkhan and @hanno-arm will be doing the reviews on hardware acceleration-related changes from now on and they need to approve this.

In the meantime, I have replied to your question here regarding the linking of MD5. Perhaps it would be good to include the change I suggested in my comment in this PR to ensure the linking problem does not persist? What are your thoughts?

adustm · 2017-12-14T13:43:11Z

Hi,
The MD5 link issue is fixed in the last commit 2c85c29.

The test is now 100% tested and OK.
This PR is ready for review.
@mazimkhan and @hanno-arm, could you proceed to the review, please ?

Kind regards
Armelle

adustm · 2017-12-19T13:45:00Z

bump...

mazimkhan

LGTM

hanno-becker · 2017-12-22T08:42:23Z

features/mbedtls/targets/TARGET_STM/md5_alt.c

@@ -175,6 +175,12 @@ void mbedtls_md5_finish( mbedtls_md5_context *ctx, unsigned char output[16] )
            return; // Return error code here
        }
    }
+    /* The following test can happen when the input is empty, and mbedtls_md5_update has never been called */


@adustm

This seems to introduce a redundancy with the pre-existing code https://github.com/ARMmbed/mbed-os/pull/5630/files#diff-00438dce44385c38da7359547815b2daR135 handling the case of an update call with an empty buffer.

Why are we not unconditionally calling HAL_HASH_MD5_Accumulate(&ctx->hhash_md5, ctx->sbuf, ctx->sbuf_len) here, even if ctx->sbuf_len == 0? Looking at the code for HAL_HASH_MD5_Accumulate, it always performs the same check for hhash_md5.Phase and updates HASH->CR if it finds HAL_HASH_PHASE_READY. Is there any problem with calling HAL_HASH_MD5_Accumulate with an empty buffer?

Hello @hanno-arm ,
Thank you for this finding.
I've tested your suggested modification and it works fine. I applied this suggestion also for SHA1 and SHA256. You can find it in the next commit.
Kind regards

adustm · 2018-01-15T16:23:41Z

Dear all,
I applied a suggestion from the code review:

diff --git a/features/mbedtls/targets/TARGET_STM/md5_alt.c b/features/mbedtls/targets/TARGET_STM/md5_alt.c
index 281e6f5..b390391 100644
--- a/features/mbedtls/targets/TARGET_STM/md5_alt.c
+++ b/features/mbedtls/targets/TARGET_STM/md5_alt.c
@@ -170,17 +170,12 @@ void mbedtls_md5_finish( mbedtls_md5_context *ctx, unsigned char output[16] )
     if (st_md5_restore_hw_context(ctx) != 1) {
         return; // Return HASH_BUSY timout error here
     }
-    if (ctx->sbuf_len > 0) {
-        if (HAL_HASH_MD5_Accumulate(&ctx->hhash_md5, ctx->sbuf, ctx->sbuf_len) != 0) {
-            return; // Return error code here
-        }
-    }
-    /* The following test can happen when the input is empty, and mbedtls_md5_update has never been called */
-    if(ctx->hhash_md5.Phase == HAL_HASH_PHASE_READY) {
-        /* Select the MD5 mode and reset the HASH processor core, so that the HASH will be ready to compute
-            the message digest of a new message */
-        HASH->CR |= HASH_ALGOSELECTION_MD5 | HASH_CR_INIT;
+    /* Last accumulation for extra bytes in sbuf_len */
+    /* This allows the HW flags to be in place in case mbedtls_sha256_update has not been called yet */
+    if (HAL_HASH_MD5_Accumulate(&ctx->hhash_md5, ctx->sbuf, ctx->sbuf_len) != 0) {
+        return; // Return error code here
     }
+

I did the same for SHA1 and SHA256.
I passed -n tests-mbedtls* for NUCLEO_F439ZI / NUCLEO_L486RG / NUCLEO_F756ZG on IAR / ARM / GCC_ARM
I also passed the test suggested in #5079 for those platforms and toolchains.

Kind regards
Armelle

hanno-becker · 2018-01-16T06:26:30Z

features/mbedtls/targets/TARGET_STM/md5_alt.c

-        }
+    /* Last accumulation for extra bytes in sbuf_len */
+    /* This allows the HW flags to be in place in case mbedtls_sha256_update has not been called yet */
+    if (HAL_HASH_MD5_Accumulate(&ctx->hhash_md5, ctx->sbuf, ctx->sbuf_len) != 0) {


@adustm Thank you for the changes! As far as I see, there's still a redundancy in xxx_update: given the current version of xxx_finish, which always calls HAL_HASH_MD5_Accumulate, it should be fine for xxx_update to be a no-op on an empty buffer.

Hello @hanno-arm
If I remove this 2nd redundancy, the md5 mbedtls-selftest is crashing, that's why I've kept it.

@adustm To be sure we understand each other correctly: As far as I understand the code, it should be fine to remove the code-path for currentlen == 0 from xxx_update - but leaving xxx_finish as it is now. In particular, it shouldn't yield any change in behavior for the testing of starts-finish without update.

Hello @hanno-arm
Thanks for insisting, I have made more tests.
The updated version of the code avoids the remaining redundancy and passes md5_selftest successfully.

Kind regards

@adustm Thank you for the rework!

cmonr · 2018-01-29T16:40:31Z

@adustm, has any progress been made on this PR?

mbed-ci · 2018-01-29T16:52:51Z

@adustm, thank you for your changes. You should get some feedback from the following people shortly: @RonEld @hanno-arm @mazimkhan please review.

…if mbedtls_xxx_udate was not called since mbedtls_xxx_start

adustm · 2018-01-30T10:20:40Z

Hi,
Last fix was implemented (commit 88c3b3e)+ tests are OK + rebase on master done.

Kind regards
Armelle

cmonr · 2018-01-30T22:00:38Z

Building whilst waiting on the last review.

/morph build

mbed-ci · 2018-01-30T22:23:34Z

Build : FAILURE

Build number : 1015
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5630/

cmonr · 2018-01-30T22:35:11Z

Failure unrelated to this PR. In the process of resolving.

0xc0170 · 2018-01-31T11:29:36Z

/morph build

mbed-ci · 2018-01-31T12:18:12Z

Build : SUCCESS

Build number : 1021
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5630/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

mbed-ci · 2018-01-31T13:25:22Z

Test : SUCCESS

Build number : 831
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5630/831

mbed-ci · 2018-01-31T14:00:22Z

Exporter Build : SUCCESS

Build number : 707
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5630/

0xc0170 · 2018-01-31T14:56:53Z

@hanno-arm Can you review the latest update. All your comments should have been addressed.

0xc0170 added needs: review component: security tracking labels Dec 1, 2017

0xc0170 requested a review from hanno-becker December 1, 2017 12:06

0xc0170 assigned mazimkhan and unassigned mazimkhan Dec 1, 2017

0xc0170 requested a review from mazimkhan December 1, 2017 12:06

ciarmcom added the mirrored label Dec 1, 2017

mazimkhan approved these changes Dec 21, 2017

View reviewed changes

hanno-becker reviewed Dec 22, 2017

View reviewed changes

0xc0170 added needs: work and removed needs: review labels Dec 22, 2017

hanno-becker reviewed Jan 16, 2018

View reviewed changes

mbed-ci added the needs: review label Jan 29, 2018

adustm added 4 commits January 30, 2018 09:41

Fix ARMmbed#5079. Add the support of call to mbedtls_xxx_finish even …

3250e2d

…if mbedtls_xxx_udate was not called since mbedtls_xxx_start

Fix MD5 link issue

cba5388

Improve fix calling Accumulate function every time in finish function

53027fd

Remove last code redundancy

88c3b3e

adustm force-pushed the fix5079_sha1_md5_sha256_hwcrypto branch from 7e18ea4 to 88c3b3e Compare January 30, 2018 10:20

0xc0170 removed the needs: work label Jan 30, 2018

cmonr mentioned this pull request Jan 30, 2018

Let libraries, targets configure bootloader #5909

Merged

1 task

hanno-becker approved these changes Jan 31, 2018

View reviewed changes

0xc0170 added ready for merge and removed needs: review tracking labels Jan 31, 2018

0xc0170 approved these changes Jan 31, 2018

View reviewed changes

cmonr merged commit c06a42b into ARMmbed:master Jan 31, 2018

cmonr added release-version: 5.7.5 and removed ready for merge component: security mirrored labels Jan 31, 2018

juhaylinen mentioned this pull request Feb 2, 2018

mbed-os-example-wifi hangs on ODIN-W2 #6003

Closed

SeppoTakalo mentioned this pull request Apr 5, 2018

Hardware acceleration is not functional #6545

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix #5079. Support of call to mbedtls_x_finish without calling mbedtls_x_update #5630

Fix #5079. Support of call to mbedtls_x_finish without calling mbedtls_x_update #5630

adustm commented Dec 1, 2017 •

edited

Loading

ciarmcom commented Dec 1, 2017

adustm commented Dec 12, 2017

andresag01 commented Dec 12, 2017 •

edited

Loading

adustm commented Dec 14, 2017

adustm commented Dec 19, 2017

mazimkhan left a comment

hanno-becker Dec 22, 2017

adustm Jan 15, 2018 •

edited

Loading

adustm commented Jan 15, 2018

hanno-becker Jan 16, 2018 •

edited

Loading

adustm Jan 18, 2018

hanno-becker Jan 18, 2018 •

edited

Loading

adustm Jan 30, 2018

hanno-becker Jan 31, 2018

cmonr commented Jan 29, 2018

mbed-ci commented Jan 29, 2018

adustm commented Jan 30, 2018 •

edited

Loading

cmonr commented Jan 30, 2018

mbed-ci commented Jan 30, 2018

cmonr commented Jan 30, 2018

0xc0170 commented Jan 31, 2018

mbed-ci commented Jan 31, 2018

mbed-ci commented Jan 31, 2018

mbed-ci commented Jan 31, 2018

0xc0170 commented Jan 31, 2018

Fix #5079. Support of call to mbedtls_x_finish without calling mbedtls_x_update #5630

Fix #5079. Support of call to mbedtls_x_finish without calling mbedtls_x_update #5630

Conversation

adustm commented Dec 1, 2017 • edited Loading

Description

Status

Steps to test or reproduce

ciarmcom commented Dec 1, 2017

adustm commented Dec 12, 2017

andresag01 commented Dec 12, 2017 • edited Loading

adustm commented Dec 14, 2017

adustm commented Dec 19, 2017

mazimkhan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adustm Jan 15, 2018 • edited Loading

Choose a reason for hiding this comment

adustm commented Jan 15, 2018

hanno-becker Jan 16, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hanno-becker Jan 18, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cmonr commented Jan 29, 2018

mbed-ci commented Jan 29, 2018

adustm commented Jan 30, 2018 • edited Loading

cmonr commented Jan 30, 2018

mbed-ci commented Jan 30, 2018

cmonr commented Jan 30, 2018

0xc0170 commented Jan 31, 2018

mbed-ci commented Jan 31, 2018

Triggering tests

mbed-ci commented Jan 31, 2018

mbed-ci commented Jan 31, 2018

0xc0170 commented Jan 31, 2018

adustm commented Dec 1, 2017 •

edited

Loading

andresag01 commented Dec 12, 2017 •

edited

Loading

adustm Jan 15, 2018 •

edited

Loading

hanno-becker Jan 16, 2018 •

edited

Loading

hanno-becker Jan 18, 2018 •

edited

Loading

adustm commented Jan 30, 2018 •

edited

Loading