NUC472/M487: Refine code with mbed TLS crypto alternatives #4925

ccli8 · 2017-08-17T08:53:06Z

Description

This PR refines code with mbed TLS crypto alternatives on code review in previous PR. It includes the following modifications:

Remove debug code in AES alternative.
Remove unnecessary macro definitions and clarify header file include.
Fix DES alternative function not thread-safe.

Related PRs

#4832
#4608

@0xc0170 @RonEld

0xc0170 · 2017-08-17T09:16:12Z

cc @yanesca @andresag01

RonEld · 2017-08-17T10:43:53Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_NUC472/aes/aes_alt.c



 static void __nvt_aes_crypt( mbedtls_aes_context *ctx,
-                          const unsigned char input[16],
-                          unsigned char output[16], int dataSize)
+                             const unsigned char input[16],


I missed this in the previous Review.
This function also seems not thread safe. au8OutputData and au8InputData are defined out of this function, as static variables, which could be overwritten every cryptographic call

@RonEld I fixed it. Please check c405d00.

RonEld · 2017-08-17T10:52:08Z

Hi @ccli8 Thank you for this PR, the code is now a lot more readable.
I have noticed that AES could also not be thread safe, and commented on that

theotherjimmy · 2017-08-21T15:22:02Z

@yanesca Thoughts?

yanesca · 2017-08-21T16:27:50Z

@theotherjimmy I didn't loose track of this PR, I am just tied down with other tasks. I will review this and the underlying two other PRs as soon as I can!

theotherjimmy · 2017-08-21T16:38:26Z

@yanesca The pings are just to make sure you don't lose track of it. Feel free to get to it when it's best for you.

yanesca · 2017-08-21T16:50:21Z

@theotherjimmy Ah ok, thank you!

yanesca · 2017-08-22T10:56:45Z

My current estimate is that I can start looking at this by the end of next week.

0xc0170 · 2017-09-01T11:00:51Z

My current estimate is that I can start looking at this by the end of next week.

@yanesca Bump for review

0xc0170 · 2017-09-01T11:01:10Z

@tommikas The jenkins CI did not report the status for this PR

tommikas · 2017-09-01T11:18:28Z

So it seems. I restarted the build. It should update once it's done.

yanesca · 2017-09-01T11:26:46Z

I am terribly sorry, but a lot has changed since my last comment and I haven't had the time to look at this yet. I don't have any estimate when that will be, but I am going to review this PR as soon as I can.

ciarmcom · 2017-09-07T16:28:02Z

ARM Internal Ref: IOTSSL-1718

andresag01 · 2017-09-12T15:46:51Z

I tried the simple stress test that I added in issue #5079 and I got the following error:

mbed assertation failed: No available AES channel, file: ./mbed-os/features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_����k96

Could you please take a look at this failure?

ccli8 · 2017-09-13T01:37:35Z

mbed assertation failed: No available AES channel, file: ./mbed-os/features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes...

@andresag01 NUC472/M480 AES H/W just supports 4 channels, but #5079 requires 12. That's the cause. Is the fix necessary? If yes, we need to merge in AES S/W (mbed-os/features/mbedtls/src/aes.c) as fallback. Because AES S/W (mbed-os/features/mbedtls/src/aes.c) and AES H/W (aes_alt.c) are mutually exclusive in current mbed TLS crypto framework, the merge-in of AES S/W would duplicate the AES S/W code.

Bump @cyliangtw

andresag01 · 2017-09-13T08:08:21Z

@ccli8: Thanks for replying. Given that there are only four channels in the device, is it possible to somehow save and restore the accelerator context somehow so that more than 4 mbedtls AES contexts are supported?

@RonEld, @yanesca, @sbutcher-arm: What do you think about this limitation?

ccli8 · 2017-09-14T03:45:44Z

Given that there are only four channels in the device, is it possible to somehow save and restore the accelerator context somehow so that more than 4 mbedtls AES contexts are supported?

@andresag01 I would try your suggestion.

ccli8 · 2017-09-14T09:13:56Z

@andresag01 To pass test code in #5079, I fix AES alter. bugs. Please check commits b9a3298 and a63c9e2.

andresag01 · 2017-09-14T09:24:53Z

@ccli8: Many thanks for considering my comments. I will take a look at the changes as soon as I can.

andresag01

@ccli8: Thank you for your contribution. I have given a first pass to the changes related to hardware acceleration and left several comments and questions.

andresag01 · 2017-09-15T09:41:52Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.c

-{
-	if( i >=0 && i < (int)sizeof(channel_flag) )
-        channel_flag[i] = 0x00;
+    unsigned int* piv;


I would prefer using uint32_t

andresag01 · 2017-09-15T09:55:17Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.h

-#endif    
+    uint32_t iv[4];
+    unsigned char prv_iv[16];
+    uint32_t buf[8];


Could you add a comment describing what this buffer is used for?

@andresag01 I add comment in 2a8875b.

andresag01 · 2017-09-15T09:57:24Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.c

+    /* We support multiple contexts with context save & restore and so needs just one 
+     * H/W channel. Always use H/W channel #0. */
+    ctx->channel = 0;
+    memset(ctx->iv, 0, sizeof (ctx->iv));


This seems slightly redundant given that you have already set the whole ctx to 0.

@andresag01 This code is refined in 2d7a33e.

andresag01 · 2017-09-15T09:58:31Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.c

+     * H/W channel. Always use H/W channel #0. */
+    ctx->channel = 0;
+    memset(ctx->iv, 0, sizeof (ctx->iv));
+
    /* Unlock protected registers */
    SYS_UnlockReg();
    CLK_EnableModuleClock(CRPT_MODULE);


Is it possible for a user to actually switch the crypto module off?

andresag01 · 2017-09-15T09:59:07Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.c

-	int i =-1;
-
-
-    mbedtls_trace("=== %s \r\n", __FUNCTION__);
    memset( ctx, 0, sizeof( mbedtls_aes_context ) );


What happens if the input pointer is NULL?

@andresag01 This follows mbed-os/features/mbedtls/src/aes.c by assuming upper layer won't pass NULL context pointer.

andresag01 · 2017-09-18T13:14:46Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/sha/sha1_alt_sw.h

-#include "config.h"
-#else
-#include MBEDTLS_CONFIG_FILE
-#endif


Same comment as above regarding config.h

andresag01 · 2017-09-18T13:18:54Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/sha/sha512_alt_sw.c


 #if defined(MBEDTLS_SHA512_C)
 #if defined(MBEDTLS_SHA512_ALT)

-#include "mbedtls/sha512.h"
-
 #if defined(_MSC_VER) || defined(__WATCOMC__)


I think this is just for windows, so not needed in mbed OS

@andresag01 Same as above.

andresag01 · 2017-09-18T13:19:14Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/sha/sha512_alt_sw.c

@@ -56,8 +50,10 @@
 #endif /* MBEDTLS_SELF_TEST */


I do not think there is a self test in this file

@andresag01 Same as above.

andresag01 · 2017-09-18T13:19:46Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/sha/sha512_alt_sw.h

-#else
-#include MBEDTLS_CONFIG_FILE
-#endif
-


Same comment as above regarding config.h

andresag01 · 2017-09-18T13:23:22Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_NUC472/sha/sha_alt_hw.h

-#else
-#include MBEDTLS_CONFIG_FILE
-#endif
-
 #if defined(MBEDTLS_SHA1_C) || defined(MBEDTLS_SHA256_C) || defined(MBEDTLS_SHA512_C)
 #if defined(MBEDTLS_SHA1_ALT) || defined(MBEDTLS_SHA256_ALT) || defined(MBEDTLS_SHA512_ALT)


I woudl suggest splitting this file into 1 file per module as with the software ones...

@andresag01 SHA1/SHA256/SHA512 share the same SHA H/W, so these code are placed together.

ccli8 · 2017-09-21T03:45:05Z

I have given a first pass to the changes related to hardware acceleration and left several comments and questions.

@andresag01 I update AES first. I would update DES and SHA later.

ccli8 · 2017-09-21T08:24:15Z

I have given a first pass to the changes related to hardware acceleration and left several comments and questions.

@andresag01 Besides AES just now, I add updates for DES and SHA. Please check them.

andresag01 · 2017-09-21T13:37:32Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.c

-        channel_flag[i] = 0x00;
+    uint32_t buff_ = (uint32_t) buff;
+
+    return (((buff_ & 0x03) == 0) && ((buff_ & 0x20000000) == 0x20000000));


I am not sure this check corresponds to the conditions that you have stated in the comment above. For example consider the value 0x30000000 that is word aligned and will also satisfy the check (buff_ & 0x20000000) == 0x20000000 even though is not in the 0x2xxxxxxx range. Perhaps I misunderstood the constraints, but I believe something like this will satisfy:

ptr % 4 == 0 && (ptr & 0xF0000000) == 0x20000000

@andresag01 Yes, you are right. I fixed it in 3119935.

andresag01 · 2017-09-21T13:41:11Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.c

-	int i =-1;
-
-
-    mbedtls_trace("=== %s \r\n", __FUNCTION__);
    memset( ctx, 0, sizeof( mbedtls_aes_context ) );


andresag01

I have reviewed the changes once again and left more comments and questions.

As a general note, I still do not understand why are there two copies of the following files:

aes_alt.c
aes_alt.h
des_alt.h
des_alt.c
etc

I compared some of these and except for aes_alt.c they seem to have exactly the same content. Also, the differences between the two aes_alt.c files is only these lines:

< #include "M480.h"
---
> #include "NUC472_442.h"
193,196c193,196
<     ctx->iv[0] = CRPT->AES_FDBCK[0];
<     ctx->iv[1] = CRPT->AES_FDBCK[1];
<     ctx->iv[2] = CRPT->AES_FDBCK[2];
<     ctx->iv[3] = CRPT->AES_FDBCK[3];
---
>     ctx->iv[0] = CRPT->AES_FDBCK0;
>     ctx->iv[1] = CRPT->AES_FDBCK1;
>     ctx->iv[2] = CRPT->AES_FDBCK2;
>     ctx->iv[3] = CRPT->AES_FDBCK3;

I do not think that differences justify the code duplication. Please take a look at the acceleration code for other targets to get an idea of what I mean.

andresag01 · 2017-09-21T13:43:34Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.c

    memset( ctx, 0, sizeof( mbedtls_aes_context ) );
-	
+
    ctx->swapType = AES_IN_OUT_SWAP;


Question, what does AES_IN_OUT_SWAP represent?

AES_IN_OUT_SWAP represents input/output data in little-endian. The code was refined in
ed39056.

andresag01 · 2017-09-21T13:45:08Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.c

-    ctx->channel = i;
-    ctx->iv = au32MyAESIV;
-
+
    /* Unlock protected registers */
    SYS_UnlockReg();
    CLK_EnableModuleClock(CRPT_MODULE);


Question: Is it possible for a user to actually switch the crypto module off when not in use? Is it necessary at all to do that in order to save power, etc?

In this commit 3aff492, crypto module clock is disabled when it is not in use.

andresag01 · 2017-09-21T13:47:39Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.c

+        ctx->buf[i] = (*(key+i*4) << 24) |
+                      (*(key+1+i*4) << 16) |
+                      (*(key+2+i*4) << 8) |
+                      (*(key+3+i*4) );


@ccli8: Perhaps I am missing something, but I do not think that commit bd0960a modifies these lines of code.

andresag01 · 2017-09-21T14:51:17Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.c

+     *   2) Located in 0x2xxxxxxx region
+     */
+    MBED_ALIGN(4) uint8_t au8OutputData[MAX_DMA_CHAIN_SIZE];
+    MBED_ALIGN(4) uint8_t au8InputData[MAX_DMA_CHAIN_SIZE];


Could you please take a look at this code again? I am not entirely sure it will work reliably given the constraints in the memory range for the DMA.

At the moment, these two buffers are being allocated in the stack. However, the thread stack is actually allocated in heap memory when a new thread is spawned. I looked at the linker script for one of the target NUC472 (XRAM_SUPPORTED) and found that:

RAM_EXTERN (rwx) : ORIGIN = 0x60000000, LENGTH = 0x00100000 ... .heap (NOLOAD): { __end__ = .; end = __end__; *(.heap*); . += (ORIGIN(RAM_EXTERN) + LENGTH(RAM_EXTERN) - .); __HeapLimit = .; } > RAM_EXTERN

Given the origin for RAM_EXTERN, it looks like these buffers will not be in 0x20000000 and the check below would be triggered for this target. However, it would work on NUC (XRAM_UNSUPPORTED). Given the constraints, I think you probably need to allocate these buffers in .bss instead, but I am not as familiar with the nuvoton linker scripts. Please feel free to consider alternatives...

@andresag01 Yes, it was a potential bug. In 20b696d, DMA buffer is now allocated at bss to guarantee it is located at 0x20000.000 region.

andresag01 · 2017-09-21T15:05:25Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.c

+            ctx->encDec = 0;
+            __nvt_aes_crypt(ctx, input, output, blockChainLen);
+            memcpy( iv, temp, 16 );
+        }


As far as I can see, this code is using three copies of the same value, just in different format:

iv: the input parameter to the function in LE

ctx->iv: same as iv but BE

temp: same as iv
Because of this, I think temp is unnecessary, but please feel free to point out any flaws in my reasoning.

@andresag01 Same as above.

andresag01 · 2017-09-22T10:07:12Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.c

+    }
+
+    /* Last incomplete block */
+    size_t last_block_len = length;


Is last_block_len really necessary?

@andresag01 I refined it in 2fd1226.

andresag01 · 2017-09-22T10:14:06Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.h

+    uint32_t opMode;        /* AES_MODE_ECB/CBC/CFB */
+    uint32_t swapType;      /* Input/Output data endianness */
+    uint32_t iv[4];         /* IV for next block cipher */
+    uint32_t buf[8];        /* Cipher key */


I think this buffer holds the BE representation of the AES keys. Perhaps we should just call the buffer key instead of buf...

@andresag01 I renamed buf to keys in 2fd1226.

andresag01 · 2017-09-22T10:15:26Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/aes/aes_alt.h

+    uint32_t keySize;       /* Key size: AES_KEY_SIZE_128/192/256 */
+    uint32_t encDec;        /* 0: decrypt, 1: encrypt */
+    uint32_t opMode;        /* AES_MODE_ECB/CBC/CFB */
+    uint32_t swapType;      /* Input/Output data endianness */


swapType seems to only ever hold one value, namely:

ctx->swapType = AES_IN_OUT_SWAP;

Is it necessary to keep this variable around?

@andresag01 I removed it in ed39056.

andresag01 · 2017-09-22T10:56:17Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/des/des_alt.c

-    while (rmn) {
+
+    // Must be a multiple of 64-bit block size
+#define MAXSIZE_DMABUF  (8 * 5)


Where does this limit come from?

@andresag01 It was roughly estimated to make a trade-off between memory footprint and performance. I commented it in 2fd1226.

andresag01 · 2017-09-22T11:01:49Z

features/mbedtls/targets/TARGET_NUVOTON/TARGET_M480/sha/sha1_alt_sw.c


 #if defined(MBEDTLS_SHA1_C)
 #if defined(MBEDTLS_SHA1_ALT)
-
-#include "mbedtls/sha1.h"
-
 #include <string.h>
 #if defined(MBEDTLS_SELF_TEST)


@ccli8: Could you please help me understand why is there a software fallback for SHA1 at all? I mean, it seems that there is an accelerator available. Is it because for some reason it is not possible to switch the accelerator context so that operations can be interleaved?

P.S. The same comment does for SHA256 and SHA512

ccli8 · 2017-09-28T01:56:55Z

As a general note, I still do not understand why are there two copies of the following files ...

@andresag01 At present, our port, like serial, i2c, spi, etc. separate code by chip family. NUC472 and M487 belong to different chip families, so there are two copies of them. In the future, we may consider merging them together when there are too many branches and it is difficult to maintain them.

…ES alter.

…o ISR

…tion completion in DES alter. This is to be consistent with PRNG/AES.

… modules

…MAC_CTL in SHA alter.

As destination/source contexts are the same, we return immediately.

…lter.

ccli8 · 2018-01-05T02:03:21Z

@0xc0170 I've done with rebase. Please check it.

0xc0170 · 2018-01-05T08:04:00Z

/morph build

mbed-ci · 2018-01-05T08:39:35Z

Build : SUCCESS

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

Triggering tests

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

mbed-ci · 2018-01-05T09:25:32Z

Exporter Build : FAILURE

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

0xc0170 · 2018-01-05T09:45:20Z

Node went offline, restarting

/morph export-build

mbed-ci · 2018-01-05T10:39:58Z

Exporter Build : SUCCESS

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

mbed-ci · 2018-01-05T15:12:54Z

Test : SUCCESS

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

0xc0170 added the needs: review label Aug 17, 2017

RonEld reviewed Aug 17, 2017

View reviewed changes

adbridge requested a review from yanesca August 24, 2017 11:36

adbridge added component: security tracking labels Sep 7, 2017

ciarmcom added the mirrored label Sep 7, 2017

andresag01 suggested changes Sep 18, 2017

View reviewed changes

andresag01 reviewed Sep 21, 2017

View reviewed changes

andresag01 suggested changes Sep 22, 2017

View reviewed changes

ccli8 added 14 commits January 5, 2018 09:18

[NUC472/M487] Fix parameter check for TMODE/OPMODE in DES alter.

dc3c84c

[NUC472] Update BSP crypto driver

9edda18

[NUC472/M487] Call BSP driver rather than direct register access in D…

c906790

…ES alter.

[NUC472/M487] Add memory barrier for DMA transfer in AES/DES alter.

b443a23

[NUC472/M487] Refine code in SHA alter.

add839c

[NUC472/M487] Add comment for crypto_zeroize

e1fbf0f

[NUC472/M487] Refine flow control code between crypto start and crypt…

0c10984

…o ISR

[NUC472/M487] Use interrupt signal rather than polling to check opera…

3a8c1aa

…tion completion in DES alter. This is to be consistent with PRNG/AES.

[NUC472/M487] Guard from reordering DMA wait and post-wait for crypto…

a00f8d0

… modules

[NUC472/M487] Remove duplicate configuration of CRPT->SHA_CTL/CRPT->H…

8b7ff09

…MAC_CTL in SHA alter.

[NUC472/M487] Fix indefinite loop in SHA alter.

d96bcda

[NUC472/M487] Fix context clone corner case in SHA alter.

acff29e

As destination/source contexts are the same, we return immediately.

[NUC472/M487] Remove unnecessary H/W context clone functions in SHA a…

4023078

…lter.

[NUC472/M487] Fix DMA input/output buffers are overlapped in AES alter.

67386b9

ccli8 force-pushed the nuvoton_crypto branch from 08c4e82 to 67386b9 Compare January 5, 2018 01:51

0xc0170 added ready for merge and removed needs: CI labels Jan 8, 2018

0xc0170 approved these changes Jan 8, 2018

View reviewed changes

theotherjimmy merged commit 3c53908 into ARMmbed:master Jan 8, 2018

theotherjimmy added release-version: 5.7.3 and removed ready for merge labels Jan 8, 2018

ciarmcom added the closed_in_jira label Jan 8, 2018

ccli8 deleted the nuvoton_crypto branch January 9, 2018 08:15

		memset( ctx, 0, sizeof( mbedtls_aes_context ) );


		ctx->swapType = AES_IN_OUT_SWAP;

NUC472/M487: Refine code with mbed TLS crypto alternatives #4925

NUC472/M487: Refine code with mbed TLS crypto alternatives #4925

Uh oh!

Conversation

ccli8 commented Aug 17, 2017

Description

Related PRs

Uh oh!

0xc0170 commented Aug 17, 2017

Uh oh!

RonEld Aug 17, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RonEld commented Aug 17, 2017

Uh oh!

theotherjimmy commented Aug 21, 2017

Uh oh!

yanesca commented Aug 21, 2017

Uh oh!

theotherjimmy commented Aug 21, 2017

Uh oh!

yanesca commented Aug 21, 2017

Uh oh!

yanesca commented Aug 22, 2017

Uh oh!

0xc0170 commented Sep 1, 2017

Uh oh!

0xc0170 commented Sep 1, 2017

Uh oh!

tommikas commented Sep 1, 2017

Uh oh!

yanesca commented Sep 1, 2017

Uh oh!

ciarmcom commented Sep 7, 2017

Uh oh!

andresag01 commented Sep 12, 2017

Uh oh!

ccli8 commented Sep 13, 2017

Uh oh!

andresag01 commented Sep 13, 2017

Uh oh!

ccli8 commented Sep 14, 2017

Uh oh!

ccli8 commented Sep 14, 2017

Uh oh!

andresag01 commented Sep 14, 2017

Uh oh!

andresag01 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

RonEld Aug 17, 2017 •

edited

Loading

andresag01 left a comment •

edited

Loading