[En-Nut-Discussion] CM4: Linking external (crypto) library

[Philipp Burch]

Hi Matthias,

thanks for the hint with micro-ecc. This could indeed work, at least it
seems to be easy to integrate from a toolchain point of view. Getting
the crypto stuff right on this lower level of abstraction will be
another story, though. But that should be doable, especially since we do
not need the absolute maximum amount of security. It should just make it
harder to simply disassemble a firmware update file.

Best regards,
Philipp

On 04.03.19 14:23, Matthias Ringwald wrote:
> Hi Philipp
> 
> I have no experience with libsodium or your actual linker issue.
> 
> When looking for a library for ECC, NaCl / libsodium seemed not suited for embedded (I guess I was wrong about that).
> Then, I've tried mbedTLS. That worked for me but mbedTLS requires malloc. I created a minimal malloc implementation, just for mbedTLS, but it required more RAM that I've liked.
> 
> Finally, I came across micro-ecc (https://github.com/kmackay/micro-ecc). It's malloc-free and works well. Maybe it is suitable for your setup as well.
> 
> Best
>  Matthias
> 
>> On 2 Mar 2019, at 17:35, Philipp Burch <phip at hb9etc.ch> wrote:
>>
>> Anyone?
>>
>> Regards,
>> Philipp
>>
>> On 08.02.19 14:54, Philipp Burch wrote:
>>> Hi everyone,
>>>
>>> I'm on the way to add encryption and signature support to the
>>> tiva_ethloader bootloader (see https://hb9etc.ch/hg/tiva_ethloader/). As
>>> a start, I looked for a suitable crypto library to do the hard work,
>>> which provides support for (symmetric) encryption and (asymmetric)
>>> signature checking. As it is planned right now, there should be no need
>>> for a random number generator on the device, so it really is only a
>>> software thing.
>>>
>>> I know that Ethernut already has some kind of crypto library included,
>>> but haven't looked closely at it yet. In the configurator, I see that
>>> AES is mentioned, but haven't seen anything that provides signature
>>> checking (could be RSA-based, or even better some EC cryptography to get
>>> away with shorter keys). Correct me, if I'm wrong. I'll happily use some
>>> existing Ethernut code if it already includes what I need.
>>>
>>> Anyway, as the topic suggests, I'm actually trying to get an external
>>> lib included in my code, libsodium
>>> (https://github.com/jedisct1/libsodium) to be exact. Compilation of the
>>> library itself for the arm-none-eabi target is quite easy and gives me
>>> the libsodium.a for inclusion.
>>>
>>> Now, when trying to add the library to the bootloader, the linker coughs
>>> because of multiple definitions of fflush() and also due to undefined
>>> references to some underlying functions like _close() and _read():
>>>
>>> ------- 8< ------- 8< -------
>>>
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-fflush.o):
>>> In function `fflush':
>>> fflush.c:(.text.fflush+0x0): multiple definition of `fflush'
>>> /home/phip/phipsfiles/developing/ethernut/nutinstall-fpm_01b/libnutcrt.a(fflush.o):fflush.c:(.text.fflush+0x0):
>>> first defined here
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld:
>>> section .ARM.exidx LMA [000000000001e0e0,000000000001e0e7] overlaps
>>> section .data LMA [000000000001e0e0,000000000001f1d7]
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-closer.o):
>>> In function `_close_r':
>>> closer.c:(.text._close_r+0xc): undefined reference to `_close'
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-readr.o):
>>> In function `_read_r':
>>> readr.c:(.text._read_r+0x12): undefined reference to `_read'
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-fstatr.o):
>>> In function `_fstat_r':
>>> fstatr.c:(.text._fstat_r+0x10): undefined reference to `_fstat'
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-isattyr.o):
>>> In function `_isatty_r':
>>> isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
>>> /usr/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc.a(lib_a-lseekr.o):
>>> In function `_lseek_r':
>>> lseekr.c:(.text._lseek_r+0x12): undefined reference to `_lseek'
>>>
>>> ------- 8< ------- 8< -------
>>>
>>> According to the paths, this is because the linker takes code from ARM's
>>> standard library, instead of the one included in Ethernut.
>>>
>>> Now the question: How can I find out what symbol triggers the inclusion
>>> of the ARM standard library? And how can I fix this? I already tried
>>> various compiler flags when compiling libsodium, also the ones that are
>>> used when compiling the Ethernut libs or the bootloader itself, but
>>> without luck, the errors stay the same.
>>>
>>> I'd be glad for any hints!
>>>
>>> Thanks and regards,
>>> Philipp
>>> _______________________________________________
>>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>>
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> 
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>