Change Details

Certain GNU/Linux distributions provide a version of gcc that has stack-smashing protection enabled by default. On these systems, building the ATF can fail with undefined-reference errors from the linker even with the ENABLE_STACK_PROTECTION build option set to "none". For example, on Void Linux, building for the Rockchip RK3328 platform with ``` make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3328 bl31 ``` fails with a large number of errors of the form ``` aarch64-linux-gnu-ld.bfd: ./build/rk3328/release/bl31/ddr_parameter.o: in function `ddr_region_usage_parse': ddr_parameter.c:(.text.ddr_region_usage_parse+0x10): undefined reference to `__stack_chk_guard' aarch64-linux-gnu-ld.bfd: ddr_parameter.c:(.text.ddr_region_usage_parse+0x14): undefined reference to `__stack_chk_guard' aarch64-linux-gnu-ld.bfd: ddr_parameter.c:(.text.ddr_region_usage_parse+0x84): undefined reference to `__stack_chk_fail' ``` This is because the build system assumes stack protection is disabled unless explicitly requested from the compiler. Adding "ENABLE_STACK_PROTECTOR=none" to the command line above doesn't solve the problem. Note that regarding this option, [[https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/user-guide.html#common-build-options | the User Guide claims]] > The default value is set to “none”... “none” disables the stack protection. but this is untrue; either omitting the option or setting it to "none" merely prevents an additional flag from being passed to the compiler, requesting the default behaviour instead, which may or may not include stack protection. The solution is to modify the implementation so the build system explicitly requests the compiler not use stack protection when the feature is expected to be disabled. I'll upload a patch that makes this change.

Certain GNU/Linux distributions provide a version of gcc that has stack-smashing protection enabled by default. On these systems, building the ATF can fail with undefined-reference errors from the linker even with the ENABLE_STACK_PROTECTOR build option set to "none". For example, on Void Linux, building for the Rockchip RK3328 platform with ``` make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3328 bl31 ``` fails with a large number of errors of the form ``` aarch64-linux-gnu-ld.bfd: ./build/rk3328/release/bl31/ddr_parameter.o: in function `ddr_region_usage_parse': ddr_parameter.c:(.text.ddr_region_usage_parse+0x10): undefined reference to `__stack_chk_guard' aarch64-linux-gnu-ld.bfd: ddr_parameter.c:(.text.ddr_region_usage_parse+0x14): undefined reference to `__stack_chk_guard' aarch64-linux-gnu-ld.bfd: ddr_parameter.c:(.text.ddr_region_usage_parse+0x84): undefined reference to `__stack_chk_fail' ``` This is because the build system assumes stack protection is disabled unless explicitly requested from the compiler. Adding "ENABLE_STACK_PROTECTOR=none" to the command line above doesn't solve the problem. Note that regarding this option, [[https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/user-guide.html#common-build-options | the User Guide claims]] > The default value is set to “none”... “none” disables the stack protection. but this is untrue; either omitting the option or setting it to "none" merely prevents an additional flag from being passed to the compiler, requesting the default behaviour instead, which may or may not include stack protection. The solution is to modify the implementation so the build system explicitly requests the compiler not use stack protection when the feature is expected to be disabled. I'll upload a patch that makes this change.

Certain GNU/Linux distributions provide a version of gcc that has stack-smashing protection enabled by default. On these systems, building the ATF can fail with undefined-reference errors from the linker even with the ENABLE_STACK_PROTECTIONOR build option set to "none". For example, on Void Linux, building for the Rockchip RK3328 platform with ``` make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3328 bl31 ``` fails with a large number of errors of the form ``` aarch64-linux-gnu-ld.bfd: ./build/rk3328/release/bl31/ddr_parameter.o: in function `ddr_region_usage_parse': ddr_parameter.c:(.text.ddr_region_usage_parse+0x10): undefined reference to `__stack_chk_guard' aarch64-linux-gnu-ld.bfd: ddr_parameter.c:(.text.ddr_region_usage_parse+0x14): undefined reference to `__stack_chk_guard' aarch64-linux-gnu-ld.bfd: ddr_parameter.c:(.text.ddr_region_usage_parse+0x84): undefined reference to `__stack_chk_fail' ``` This is because the build system assumes stack protection is disabled unless explicitly requested from the compiler. Adding "ENABLE_STACK_PROTECTOR=none" to the command line above doesn't solve the problem. Note that regarding this option, [[https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/user-guide.html#common-build-options | the User Guide claims]] > The default value is set to “none”... “none” disables the stack protection. but this is untrue; either omitting the option or setting it to "none" merely prevents an additional flag from being passed to the compiler, requesting the default behaviour instead, which may or may not include stack protection. The solution is to modify the implementation so the build system explicitly requests the compiler not use stack protection when the feature is expected to be disabled. I'll upload a patch that makes this change.