Skip to content
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

[nRF Connect] Use hardware-accelerated crypto functions #2370

Merged
merged 1 commit into from
Aug 28, 2020

Conversation

Damian-Nordic
Copy link
Contributor

Problem

nRF Connect lock-app uses Zephyr's built-in mbedtls which doesn't include hardware-accelerated cryptographic functions.

Summary of Changes

Configure the example to use nrf_security library which provides implementation optimized for Nordic platforms.

fixes #2369

Use mbedTLS from nrf_security library which provides
hardware-accelerated cryptographic functions.
@github-actions
Copy link

Size increase report for "nrfconnect-example-build"

File Section File VM
chip-nrf52840-lock-example.elf text 102072 102072
chip-nrf52840-lock-example.elf bss 0 14796
chip-nrf52840-lock-example.elf rodata 2864 2864
chip-nrf52840-lock-example.elf datas 68 68
chip-nrf52840-lock-example.elf [LOAD #3 [RW]] 0 20
chip-nrf52840-lock-example.elf [LOAD #2 [RW]] -4 -4
chip-nrf52840-lock-example.elf [LOAD #1 [RWX]] -8 -8
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-nrf52840-lock-example.elf and ./pull_artifact/chip-nrf52840-lock-example.elf:

sections,vmsize,filesize
.debug_info,0,305709
text,102072,102072
.debug_line,0,48791
.debug_loc,0,47739
.symtab,0,26448
.strtab,0,15918
bss,14796,0
.debug_str,0,12383
.debug_abbrev,0,8853
.debug_frame,0,4784
.debug_ranges,0,3880
rodata,2864,2864
.debug_aranges,0,1648
datas,68,68
[LOAD #3 [RW]],20,0
[Unmapped],0,3
[LOAD #2 [RW]],-4,-4
[LOAD #1 [RWX]],-8,-8


@github-actions
Copy link

Size increase report for "esp32-example-build"

File Section File VM
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-wifi-echo.elf and ./pull_artifact/chip-wifi-echo.elf:

sections,vmsize,filesize


@github-actions
Copy link

Size increase report for "gn_nrf-example-build"

File Section File VM
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv


@github-actions
Copy link

Size increase report for "gn_linux-example-build"

File Section File VM
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv


@github-actions
Copy link

Size increase report for "gn_efr32-example-build"

File Section File VM
Full report output
BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-efr32-lock-example.out and ./pull_artifact/chip-efr32-lock-example.out:

sections,vmsize,filesize


@@ -74,7 +74,7 @@ jobs:
runs-on: ubuntu-latest

container:
image: connectedhomeip/chip-build-nrf-platform:0.4.1
image: connectedhomeip/chip-build-nrf-platform:0.4.2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this image pushed yet?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes and no :)
Initially I asked Andrei to rebuild nrf image with "--no-cache" flag so that fresh sources are picked up. Later we agreed that a cleaner approach would be using specific commit-ids in Dockerfile and not having to bypass the docker cache, so I updated the definition as you have seen. The 0.4.2 image which is on dockerhub right now is the one built with "--no-cache", so it's not the final version yet, but is good enough to build this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will have to merge them ... I originally needed 0.4.2 to have a JDK in the android-build, so I built one and Damian noticed that the nRF build was odd. We probably want both the nRF build updates and JDK commits in before we create another 'real/final 0.4.3'.

That being said, I have no plans to push any other 0.4.2 until then so this should be safe.

@andy31415 andy31415 requested a review from mspang August 28, 2020 15:33
@rwalker-apple rwalker-apple merged commit 1a91eaa into project-chip:master Aug 28, 2020
@Damian-Nordic Damian-Nordic deleted the feature/nrfsec branch September 9, 2020 13:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[nRF Connect] Use hardware-accelerated crypto functions
5 participants