K82 : newlib and newnanolib usage

[EugeneHiihtaja]

Hello !

I have try to use newnanolib none and nanolib with latest SDK and ide and linker always generate errors like this

I have tried to add -specs=nano.specs -specs=nosys.specs as suggested in migration guide and nothing dosn't help.

All setting for compiler, linker file, assembler looks correct for __NEWLIB__ usage.

Redlib none works fine with my project. But all trials to switch to new libraries is give compilation errors.

Regards,

Eugene

:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc.a(lib_a-abort.o): in function `abort':
abort.c:(.text.abort+0xa): undefined reference to `_exit'
c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc.a(lib_a-signalr.o): in function `_kill_r':
signalr.c:(.text._kill_r+0x10): undefined reference to `_kill'
c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc.a(lib_a-signalr.o): in function `_getpid_r':
signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'
c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc.a(lib_a-writer.o): in function `_write_r':
writer.c:(.text._write_r+0x12): undefined reference to `_write'
c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc.a(lib_a-closer.o): in function `_close_r':
closer.c:(.text._close_r+0xc): undefined reference to `_close'
c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc.a(lib_a-fstatr.o): in function `_fstat_r':
fstatr.c:(.text._fstat_r+0x10): undefined reference to `_fstat'
c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc.a(lib_a-isattyr.o): in function `_isatty_r':
isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc.a(lib_a-lseekr.o): in function `_lseek_r':
lseekr.c:(.text._lseek_r+0x12): undefined reference to `_lseek'
c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/nxp/mcuxpressoide_11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.win32_11.0.1.201907311258/tools/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc.a(lib_a-readr.o): in function `_read_r':
readr.c:(.text._read_r+0x12): undefined reference to `_read'

[soledad]

Hi, 

Could you confirm that this issue is the same than this https://community.nxp.com/thread/512420 

Regards 

Soledad

[EugeneHiihtaja]

Hi Soledad !

Really not. 

-fstack_protector is really implemented in newlib and instrumentation is clearly visible in dump.

But stack protector is used one global variable __stack_chk_guard and it make it unusable in case of MPU enabled RTOS when all tasks running with user privileges and it shouldn't be any common memory space.

But in case of  simple RTOS ( what is part of your SDK ) it should be possible to use -fstack_protector instead of watermarking.

But it is no evidence if stack protector feature is implemented in right way in that hoge set of libraries what you provide.

And I try to get some info about it.

E.g what kind of hardening GCC options can be recommended by NXP to  be used if MCUExpresso toolset in use ?

Not everything can be implemented.

Regards,

Eugene

[ErichStyger]

Hi Eugene,

you might have a read at Stack Canaries with GCC: Checking for Stack Overflow at Runtime | MCU on Eclipse  on that subject. The thing is that the gcc StackGuard feature has been implemented against buffer overflow exploits, so it is mainly a security feature. The canary is placed in the function call stack context and catches modifications in that stack frame, and not for a general stack overflow. But you can see from above article that indeed the canary can be used in a reverse way to check against a general stack overflow. But because there can be only one main canary value, you can only check a single thread/task stack, and not all the task stacks. Here is where the FreeRTOS stack overflow checking comes into play: it is able to protect all stacks/threads/tasks that way. You still can combine that with the gcc StackGuard, but then it is against exploits and not against general stack overflow.

I hope this makes sense and it helps,

Erich

[EugeneHiihtaja]

Hi Erich !

Thank you for good link !

So I understand right :

- newlib and newlibnano have support for even -fstack-protector-strong ( "Strong" stack protection for GCC [LWN.net]  )

 but redlib dosn't have it at all.

- stack protector  under RTOS can be used for protect MSP stack only. It looks like instrument all possible functions but 

  only when MSP stack is active actual check is done. But it is not possible to specify what exact functions can have instrumentation.

  It can be a lot of instrumented functions in task context when PSP stack is active but they just waste code space.

- in MPU enabled RTOS, stack protector is evan cause extra problem, becouse task's stack is allocated in memory what is not visible even to kernel if task context is not active and global variable __stack_chk_guard shouln't be accessed from  user task context due

full isolation of memory between user task.

- for RTOS better to use configCHECK_FOR_STACK_OVERFLOW         (2) and add auto wipe stack feature for clean values in stack

what is no need any more.

#if( ( configCHECK_FOR_STACK_OVERFLOW > 1 ) && ( portSTACK_GROWTH < 0 ) )

#if ( configWIPE_STACK_AUTO == 1 )

#define taskCHECK_FOR_STACK_OVERFLOW() \
{ \
const uint32_t * const pulStack = ( uint32_t * ) pxCurrentTCB->pxStack; \
const uint32_t ulCheckValue = ( uint32_t ) 0xa5a5a5a5; \
\
if( ( pulStack[ 0 ] != ulCheckValue ) || \
( pulStack[ 1 ] != ulCheckValue ) || \
( pulStack[ 2 ] != ulCheckValue ) || \
( pulStack[ 3 ] != ulCheckValue ) ) \
{ \
vApplicationStackOverflowHook( ( TaskHandle_t ) pxCurrentTCB, pxCurrentTCB->pcTaskName ); \
} else { \
\
/* Wipe task's stack */ \
const uint32_t * const topStack = ( uint32_t * ) pxCurrentTCB->pxTopOfStack; \
for ( volatile uint32_t * ptr = (uint32_t *)pulStack; ptr < (uint32_t *)topStack; ptr++ ) { \
ptr[0] = ulCheckValue; } \
\
} \
}

What do you think about this feature ? ( autowipe stack at task switch point ).

In critical code it is possible to initiate task reschedule for initiate clean loop. And in tickless implementation this clean is not happens so often.

-  all buffers allocated in stack should be wiped before and after usage for clearly sense used space in stack.

  It should help for detect stack overflow because buffer can be allocated but not fully used and watermarking remains.

  Post wipe is need for clean sensitive information.

By the way, could you suggest righ implementation for secure memset ( memset_s) what is not removed by modern aggressive compilers ?

mbedtls have secure memset implementation but it also under suspicion:

"

__attribute__((section(".constdata"))) static void * (* const volatile memset_func)( void *, int, size_t ) = memset; //

void mbedtls_platform_zeroize( void *buf, size_t len )
{
memset_func( buf, 0, len );
}

"

  - so you think stack protector should be removed at all and only configCHECK_FOR_STACK_OVERFLOW is taken in use ?

Please suggest !

Regards,

Eugene

[ErichStyger]

Hi Eugene,

you are asking a lot of different things, which are hard to answer just in a single answer. As a suggestion, you better split them up into separate topics.

As for instrumenting functions: see that quoted article (Stack Canaries with GCC: Checking for Stack Overflow at Runtime | MCU on Eclipse ): using attributes you can easily exclude files, and using options per file (see as well Different Ways of Software Configuration | MCU on Eclipse ) you can do instrumentation on a file by file basis.

If MSP or PSP: If you check out the actual implementation of gcc for Stack Guards, you should realize that this really does not depend on the type of stack: it is limited to the fact that there is a global canary, and not a dedicated one for each task/thread. If you want that, you could change/extend and contribute something to the FreeRTOS project, or discuss this in the FreeRTOS discussion group at FreeRTOS Real Time Kernel (RTOS) / Discussion . Same for your autowipe suggestion (you might have a look at the FreeRTOS ARM Cortex-M33 with TrustZone (see as well TrustZone with ARMv8-M and the NXP LPC55S69-EVK | MCU on Eclipse ).

As for RedLib/Newlib/Newlib-nano: it sounds to me that your use case demands that you recompile the libraries: that way you have full control over what you need. Just my $1c.

I hope this helps,

Erich

[EugeneHiihtaja]

Hi Erich !

I think with -fstack-protector-explicit possible to instrument one important task or all ISR handlers.

But in case of task may be watermarking should be disabled.

May be have sense to have per task configuration when 2 methods for stack overflow and stack protector can work together

some how.

Regards,

Eugene

[ErichStyger]

It looks to me you have chosen the (none) variant of the library. In that case your project has to provide all the standard I/O and file I/O routines (that's the ones you reported by your linker).

I suggest you select the (nohost) version, because this one implements the necessary dummy stubs:

I hope this helps,

Erich

[EugeneHiihtaja]

Hi Erich !

Thank you ! It help.

I can see in my case that NewNanoLib nohost is more fat than RedLib nohost.

Binary size 208480 bytes instead of 203200 with Redlib variant.

Have you seen any detail documentation what exact functions is implemented there ?

What libraries has better quality RedLib or NewLibNano ?

I can read some complains in internet like this :  newlib and FreeRTOS 

I get impression that RedLib is smaller and it is more tested and reliable. But what is NXP recommendations ?

It is a lot of different version of RedLib are offered now and it should be reason what all 3 sets of libs are promoted by NXP for NXP's MCU.

I'm interesting in what libraries those features are implemented and work well.

- FORTIFY_SOURCE = 2 and stack protector -  FORTIFY_SOURCE — Idea of the day 

- builtin functions for detect overflow - Using the GNU Compiler Collection (GCC): Integer Overflow Builtins 

Regards,

Eugene

[soledad]

Hi, 

Please check the following links: 

How to Switch C/C++ Library in MCUXpresso IDE 

What are none, nohost and semihost libraries? 

Newlib-Nano Support 

https://community.nxp.com/thread/389152 

I hope this helps, 

Have a nice day!

Regards 

Soledad

[EugeneHiihtaja]

Hello !

Main question was about  -fstack_protector usage instead of INCLUDE_uxTaskGetStackHighWaterMark2 method what is part of RTOS port for NXP.

Does it included to newlib nano by default, how reliable it ?

Regards,

Eugene

[ErichStyger]

Hi Eugene,

The INCLUDE_uxTaskGetStackHighWaterMark2 is more reliable because it compares a range of 16 values on the stack, while the GNU StackGuard is checking a single 32bit value.

Plus the FreeRTOS way is for all task stacks, while with the gcc way you can only protect one stack.

Or see Stack Canaries with GCC: Checking for Stack Overflow at Runtime | MCU on Eclipse 

I hope this helps,

Erich