Flash security .cfmconfig block optimized away by RVCT

ChibiOS public support forum for topics related to the Freescale Kinetis family of micro-controllers.

Moderator: utzig

fpga_comp
Posts: 16
Joined: Thu Aug 28, 2014 2:00 pm

Flash security .cfmconfig block optimized away by RVCT

Postby fpga_comp » Tue Aug 11, 2015 4:47 pm

I am trying to compile ChibiOS 3.0.0 stable release on RVCT compiler V 5.05 update 1 (build 106). I have bricked a Teensy LC (Kinetis KL26) already because the security block inside hal_lld.c has optimized away by the C compiler. i.e. the security location was overwritten by other pieces of code and irreversibly disable the bulk erase function.

Note: KL26 is close enough to KL25 FREESCALE_FREEDOM_KL25Z" with minor differences in peripherals.

The security block inside hal_lld.c

Code: Select all

/*===========================================================================*/
/* Driver local variables and types.                                         */
/*===========================================================================*/

__attribute__ ((section(".cfmconfig")))
const uint8_t _cfm[0x10] = {
  0xFF,  /* NV_BACKKEY3: KEY=0xFF */
  0xFF,  /* NV_BACKKEY2: KEY=0xFF */
  0xFF,  /* NV_BACKKEY1: KEY=0xFF */
  :
  :


Image

I will be using a modified version of the Freescale startup code which has the block inside their assembly code, their security block is at the correct location.

Code: Select all

                IF      :LNOT::DEF:RAM_TARGET
                AREA    |.ARM.__at_0x400|, CODE, READONLY
                DCB     BackDoorK0, BackDoorK1, BackDoorK2, BackDoorK3
                DCB     BackDoorK4, BackDoorK5, BackDoorK6, BackDoorK7
                DCB     FPROT0,     FPROT1,     FPROT2,     FPROT3
                DCB     FSEC,       FOPT,       0xFF,     0xFF
                ENDIF


Code: Select all

    .ARM.__at_0x400                          0x00000400   Section       16  startup_mkl16.o(.ARM.__at_0x400)


:!: So please double check the map file to make sure that the security block is indeed when you think it is!
:!: Might want to rethink that security block strategy to make sure that the compile cannot optimize it away. Don't make the assumption that if it is in the C code, then it will be in the image. What is the behavior of one compiler might not be the same on a different version or a different one.

utzig
Posts: 354
Joined: Sat Jan 07, 2012 6:22 pm
Location: Brazil
Has thanked: 1 time
Been thanked: 16 times
Contact:

Re: Flash security .cfmconfig block optimized away by RVCT

Postby utzig » Tue Aug 11, 2015 6:37 pm

I'm pretty sure gcc is acting correctly for this. I don't really have RVCT and know nothing about it, but if you can make/suggest a patch I would be glad to apply (it could even be some #pragma to disable to removal).

Cheers,
Fabio Utzig

fpga_comp
Posts: 16
Joined: Thu Aug 28, 2014 2:00 pm

Re: Flash security .cfmconfig block optimized away by RVCT

Postby fpga_comp » Tue Aug 11, 2015 11:58 pm

I don't know whether the existing code works correctly for IAR compiler, so I only change the behavior specifically for RVCT.
This uses the section ".ARM.__at_0x400" for RVCT and now the block is preserved and at the right location.

Code: Select all

#ifdef __CC_ARM
__attribute__ ((section(".ARM.__at_0x400")))
#else
__attribute__ ((section(".cfmconfig")))
#endif

FYI: ARM Linker: "Using __at sections to place sections at a specific address"
http://infocenter.arm.com/help/index.js ... BBAEE.html

utzig
Posts: 354
Joined: Sat Jan 07, 2012 6:22 pm
Location: Brazil
Has thanked: 1 time
Been thanked: 16 times
Contact:

Re: Flash security .cfmconfig block optimized away by RVCT

Postby utzig » Wed Aug 12, 2015 1:38 am

Thanks, I applied the patch. Hopefully it should have been corrected now and not cause trouble to other users.

Cheers,
Fabio Utzig

flabbergast
Posts: 71
Joined: Sat Aug 22, 2015 1:22 pm

Re: Flash security .cfmconfig block optimized away by RVCT

Postby flabbergast » Sun Sep 20, 2015 12:27 pm

I'm probably having trouble with this. Compiling ChibiOS git /demos/KINETIS/RT-TEENSY3 with gcc (4.9.3 20150529) gives

Code: Select all

.cfmprotect
 *(.cfmconfig)
                0x0000000000000100                _text = .
in build/ch.map
and /demos/KINETIS/RT-FREEDOM-KL25Z

Code: Select all

.cfmprotect
 *(.cfmconfig)
                0x00000000000000c0                _text = .
in build/ch.map. The actual section (16 bytes on 0x400) was just zeroes.

I didn't try it on the teensy (fortunately), but I did try to upload to FRDM-KL25Z and it *was* causing problems (the MBED bootloader refused to upload; loading through gdb/CMSIS-DAP resulted in running code, but subsequently inaccessible MCU through debugger.

When I compile RedoX's teensy branch it places the cfmprotect section at the right place, so I'll try to understand how does he do it.

EDIT: ChibiOS.git /testhal/KINETIS/I2C also places cfmconfig at the right place. ???

flabbergast
Posts: 71
Joined: Sat Aug 22, 2015 1:22 pm

Re: Flash security .cfmconfig block optimized away by RVCT

Postby flabbergast » Sun Sep 20, 2015 1:13 pm

Found it: It's the USE_LTO setting in the Makefile. If enabled, cfmconfig is optimized away. Is there a way to protect against this?

EDIT: This can be fixed for gcc by adding 'used' attribute:

Code: Select all

__attribute__ ((used,section(".cfmconfig")))
in os/hal/ports/KINETIS/KL2x/hal_lld.c:40
But I don't really know much about gcc and/or other compilers, so could anyone more knowledgeable please check this? Works for me, even with USE_LTO=yes.

flabbergast
Posts: 71
Joined: Sat Aug 22, 2015 1:22 pm

Re: Flash security .cfmconfig block optimized away by RVCT

Postby flabbergast » Sun Sep 20, 2015 6:26 pm

However this solution interferes with the MCHCK patch I posted in the other thread - the point is that this forces the flashcfg section to always be non-zero at 0x400, so the generated firmware binary for MCHCK does not start at 0xc00, but at 0x400. How to reconcile these? Is there a trick that could be used in the linker script, or should I just make another separate linker script for MCHCK (although it uses the same mk20dx128 chip) which would put the flashcfg bytes somewhere later (they'll just be ignored by the firmware and MCU)? Or should I attempt some #define/#if hackery in hal_lld.c?

flabbergast
Posts: 71
Joined: Sat Aug 22, 2015 1:22 pm

Re: Flash security .cfmconfig block optimized away by RVCT

Postby flabbergast » Thu Sep 24, 2015 11:37 am

Decided to create extra linker script(s) for MCHCK, to move the cfmconfig section to a dummy place after the bootloader. See the commit here. Please let me know if this is not a good solution (I mean it works, it is just not completely clean), and how could I do it in a better way.

utzig
Posts: 354
Joined: Sat Jan 07, 2012 6:22 pm
Location: Brazil
Has thanked: 1 time
Been thanked: 16 times
Contact:

Re: Flash security .cfmconfig block optimized away by RVCT

Postby utzig » Sun Sep 27, 2015 12:13 am

I'm really curious about the need of the flash_config section at all when using a bootloader. Since the firmware will be stored way beyond the place where the flash configuration is found, would the linker script even need it? Would removing the flash config section and moving the vectors to the the same flash section cause any harm?

What I'm thinking is something in the following lines: https://gist.github.com/utzig/623267a7b21c3b0b153e

Cheers,
Fabio Utzig

flabbergast
Posts: 71
Joined: Sat Aug 22, 2015 1:22 pm

Re: Flash security .cfmconfig block optimized away by RVCT

Postby flabbergast » Sun Sep 27, 2015 8:34 am

Yes, that works, thanks! (The flash should start at 0xc00, since that's where the bootloader ends - before there was an extra "flash0" section for .isr, and since it's no longer there - it absorbed to "flash", "flash" should move from 0xd10 to 0xc00.)

(I've committed it into my tree here.)


Return to “Kinetis Support”

Who is online

Users browsing this forum: No registered users and 1 guest