Skip to main content
Associate III
March 20, 2024
Solved

STM32CubeIDE 1.15.0: elf has a LOAD segment with RWX permissions

  • March 20, 2024
  • 46 replies
  • 75519 views

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

This topic has been closed for replies.
Best answer by JensH

Hi @RajeevAroraCrcEvans,

i have added an example.

You have copied every part, thats not correct.

Delete this part:

 .ARM.extab : {
 . = ALIGN(4);
 *(.ARM.extab* .gnu.linkonce.armextab.*)
 . = ALIGN(4);
 } >FLASH

 Just use this:

.ARM.extab (READONLY) : {
 . = ALIGN(4);
 *(.ARM.extab* .gnu.linkonce.armextab.*)
 . = ALIGN(4);
 } >FLASH

 And also at the other parts.

Best regards,

Jens

46 replies

PHolt.1
Senior
April 1, 2024

Yes; this is all because cube v1.15.0 updates the GCC tools from v11 to v12.

Normally you can expect various things to break when tools are upgraded.

Solution is to not change the tools. Revert to Cube 1.14.1.

 

PHolt.1
Senior
April 1, 2024

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.

 

Visitor II
April 1, 2024

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
Associate
April 3, 2024

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
Senior
April 3, 2024

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

PHolt1_0-1712154401590.png

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

 

Pavel A.
April 3, 2024

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... ?)

@mƎALLEm 

PHolt.1
Senior
April 3, 2024

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
ST Employee
April 5, 2024

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
Senior
April 5, 2024

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.

 

PHolt.1
Senior
July 26, 2024

The linker options supplied further back in this thread are invalid for GCC.

PHolt1_0-1721984414214.png

 

I have Cube IDE v 1.16.0.

Brian TIDAL
ST Technical Moderator
July 26, 2024

Hi,

make sure to use -Wl,--no-warn-rwx-segment in order to pass the --no-warn-rwx-segment option to the linker. See option for linking in the GCC documentation.

BrianTIDAL_0-1721994097485.png

 

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
PHolt.1
Senior
July 26, 2024

Thank you, but I went back to 1.14.1 because I could not get 1.16.0 to work with any debugger I have. I might revisit this with 1.16.1 :grinning_face: