STM32CubeIDE 1.15.0: elf has a LOAD segment with RWX permissions

[RajeevAroraCrcEvans]

Hi @Imen.D  , @Khouloud ZEMMELI ,

After updating the STM32CubeIDE to version 1.15.0 (today) I am observing below warning.

The LD file has not changed. It has RAM and MRAM RWX

C:/ST/STM32CubeIDE_1.15.0/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.12.3.rel1.win32_1.0.100.202403111256/tools/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld.exe: warning: xxx.elf has a LOAD segment with RWX permissions

Memory sections in LD file:

MEMORY
{
ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 2048K
DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 512K
RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 288K
RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 64K
MRAM (xrw) : ORIGIN = 0x60000000, LENGTH = 1024K
}

Please help resolve the concern.

Regards,

Rajeev

[PHolt.1]

Yeah but if you generate a new project (implying using Cube MX) you are into a whole new world of pain, because you get handed a ton of bloatware which only half works.

I can't imagine an auto generated linkfile working for anything beyond completely trivial.

[robbox123]

I've already had enough with the SPC5 tools that are a nightmare. Now it seems the ST32 tools are as bad. Why do they do this to us? All I did was download the defaults and followed the instructions. Embedded programming should not be that much hassle.

[SGran.5]

Today I updated to 1.15.0 - I got the same nightmare - what's happening? have the creators of IDE gone crazy?? owner - stop your programmers, otherwise people will start leaving this platform for competitors!

[PHolt.1]

As posted countless times: this is because cube 1.15 upgrades the GCC tools from v11 to v12.

You can revert the tools back to v11 here

Or uninstall cube and install 1.14.1 which is still on the ST website (for not much longer so grab it quick!)

[SGran.5]

it doesn't work for me((

[SGran.5]

Only your advice helped, thank you!!!

[Pavel A.]

Can this warning about writable& executable sections be suppressed for good via the .specs file in the toolchain?

It's clear why it was added in GCC, but not helpful in small baremetal systems such as STM32. What others do (Segger... ?)

@SofLit 

[PHolt.1]

Yes - here: https://tinyurl.com/y42wkzdr

I am using tiny URL because this forum software removes certain letter sequences even from URLs :face_with_tears_of_joy:

[Guillaume K]

Hello

There's a reason for the new RWX warning introduced in linker from GNU binutils v2.39:

GNU Binutils 2.39 Released

"

  * The ELF linker will now generate a warning message if the stack is made
    executable.  Similarly it will warn if the output binary contains a
    segment with all three of the read, write and execute permission
    bits set.  These warnings are intended to help developers identify
    programs which might be vulnerable to attack via these executable
    memory regions.

 Some more explanation:

The linker’s warnings about executable stacks and segments (redhat.com)

With release 2.39 of the GNU Binutils several new warnings have been added to the linker. 
While new warnings are not normally an issue, these ones are special as they have the potential 
to be triggered on programs that have previously compiled and linked without any problems.

The warnings cover two related areas—the program’s stack and the program’s code and data segments.
Both of these are prime targets for attackers—if they can insert instructions into either region,
then they can use them as stepping stones to take over the program. This is normally prevented by 
making sure that neither the stack nor the data segment can contain code and that the code segment 
cannot be modified. The new warnings are there to alert developers when these safety conditions are 
not in place.

Sometimes there are good reasons for having an executable stack or a writable code segment. 
It may be needed by the program loader in order to make a program work, or it could be needed 
by the compiler in order to implement a specific feature of the program. But it is better that 
the developer knows that this is happening, and that their programs are potentially vulnerable, 
rather than they live in ignorance.

The linker does provide command line options to turn off the warnings, and it can even be built 
with the warnings disabled by default. But the point of this blog is to provide a reference for 
developers who encounter the warnings and wonder what they can do about them.

[PHolt.1]

This warning is a bit meaningless in the ST Cube IDE context because most of the time the stack is not defined in the linkfile, so the linker can't be aware of it.