elf has a LOAD segment with RWX permissions when using .RamFunc functions

[RobDeatherage]

I've seen other posts to resolve the compiler warning of "elf has a LOAD segment with RWX permissions", but I'm receiving this warning only when calling functions in RAM using the .RamFunc segment attribute.

 

From the map file I've verified the function is being loaded into RAM.  I could disable the warning, but would like to understand the underlying issue.

 

I'm working with the latest STMCubeIDE version 1.16.0, but also saw this in 1.15.0.  I'm building code for the STM3H735 and STM32H745 families.

[TDK]

Issue is probably write + execute. Typically you don't have write permission to sections where you are executing code. Code should be static.

Try the READONLY attribute.

ld - GNU Linker: ELF has a LOAD segment with RWX permissions. Embedded ARM project - Stack Overflow

[RobDeatherage]

TDK,

Admittedly I'm relatively new to the GCC realm, and I appreciate the support.

The examples from the link you provided are referring to functions in flash, and my linker file already has READONLY attribues for all flash sections.

I've taken my original function definition of:

__attribute__ ((section (".RamFunc"))) void SomeFunction(void)

and instead, tried:

__attribute__ ((READONLY, section (".RamFunc"))) void SomeFunction(void)

but the compiler now gives an addditional warning of 'READONLY' attribute directive ignored [-Wattributes].

Am I missing what you've recommended to eliminate this warning?

[TDK]

You should make the changes in the linker file, which is a *.ld file, generally in the top level directory of the project.

Can you attach your linker file?

[Pavel A.]

The .ld files shipped with CubeIDE have the "w" attribute for the internal flash. (For 'historic reasons' ?)

Actually the flash can be declared as "rx" because it is not writable from the linker POV. The linker does not care about runtime behavior, it is not aware of MPU and so on. So it's up to the developers how they get rid of this warning.

 

[Pavel A.]

The RAM code (by contrast with flash) indeed is in memory both writable and executable. So now you do understand the reason and can disable the warning.

 

[RobDeatherage]

Paul,

I agree to some extent, but only if the warning could be suppressed for each individual function.  The warning could be beneficial in other scenarios.

Knowing memory is both writable and executable, what I would expect is for the Linker to have a little more intelligence and ignore this waring when raised due to .RamFunc functions.

I appreciate the feedback.

[TDK]

The warning is there because you're executing from a section that is writable, so a bug in the code that allowed an out of bounds write or a buffer overflow could allow for arbitrary code execution. It's not a per-function warning, but a general "this section is problematic because you can write to it and execute from it" warning. Any sort of per-function flag wouldn't address the core issue.

[RobDeatherage]

The points you and Paul have made make sense and I appreciate your feedback.

[Iampritesh]

Hi,

try creating another project with the default setting, don't add any drivers and copy yourController_FLASH.Id (e.g., yourController = STM32F401 ) content to your project's file & rebuild project. That should be fine afterwards.

[nicolas]

I had the same problem and I generated new .ld files and saw there was some "(READONLY)" missing in my files.
There is also another thread about this problem: https://community.st.com/t5/stm32cubeide-mcus/stm32cubeide-1-15-0-elf-has-a-load-segment-with-rwx-permissions/td-p/652335

[Carl_G]

I'd like a bit more clarity on this one. Typically I have seen flash writing routines loaded into RAM in order to supporting writing to FLASH. Often FLASH does not allow itself to be written to by a routine that is also executing from that same flash. Thus, you put the flash writing routine in RAM and execute from there.

I can see that 

 

 

*(.RamFunc)
.RamFunc 0x200003ac 0x88 ./Drivers/STM32G0xx_HAL_Driver/Src/stm32g0xx_hal_flash.o

 

 

Is going into RAM and causing RAM to be executable. However, I can't see where this code is put into the RamFunc section. So I can't tell what its doing and if it needs to be in RAM. Can someone confirm that it is OK to put this code into FLASH and that it will still work fine from there.

 

[TDK]

> Can someone confirm that it is OK to put this code into FLASH and that it will still work fine from there.

You can erase and write to flash from code running in flash. The MCU will stall until the erase operation is over, then continue on. Obviously, if you erase the code that is currently executing the chip will hard fault shortly thereafter.

[Carl_G]

Good to know there are no RWW restrictions on this MCU. That being the case I wonder why this code was put into RAM!? I use this for eeprom emulation on a flash area that is not executable.

[Pavel A.]

There are reasons to run code from internal RAM. This is perfectly legal. The si*l*l*y linker warning was added in some recent toolchain version. It can be ignored. ST hasn't bothered to silence it in their default GNU tools settings (the specs file) so we have to do this on ours own. Linking images for STM32 worked just fine long before this new linker version with the annoying warning.

 

[Carl_G]

I get the warning. My application isn't networked so I don't have any exploit risk. So I'll just stick this code in ROM and move along...

[Uwe Bonnes]

It is a pity that no more specific warning is given! The error message should stat _what_ section!