At my workplace, I ran:
make distclean
make sandbox_defconfig
make all
The result:
LTO u-boot
/usr/bin/ld: /tmp/ccvKFEMH.ltrans0.ltrans.o: in function `pci_io_read':
/home/mclauam/gitclone/u-boot/arch/sandbox/lib/pci_io.c:52:(.text+0x3d1):
undefined reference to `__stack_chk_guard'
/usr/bin/ld: /tmp/ccvKFEMH.ltrans0.ltrans.o: in function `get_token':
/home/mclauam/gitclone/u-boot/boot/pxe_utils.c:943:(.text+0x755): undefined
reference to `__stack_chk_guard'
/usr/bin/ld: /tmp/ccvKFEMH.ltrans0.ltrans.o: in function `parse_sliteral':
/home/mclauam/gitclone/u-boot/boot/pxe_utils.c:1010:(.text+0x898): undefined
reference to `__stack_chk_guard'
/usr/bin/ld: /tmp/ccvKFEMH.ltrans0.ltrans.o: in function `parse_integer':
/home/mclauam/gitclone/u-boot/boot/pxe_utils.c:1030:(.text+0x91a): undefined
reference to `__stack_chk_guard'
/usr/bin/ld: /tmp/ccvKFEMH.ltrans0.ltrans.o: in function `os_printf':
/home/mclauam/gitclone/u-boot/arch/sandbox/cpu/os.c:59:(.text+0xb3c): undefined
reference to `__stack_chk_guard'
/usr/bin/ld:
/tmp/ccvKFEMH.ltrans0.ltrans.o:/home/mclauam/gitclone/u-boot/arch/sandbox/cpu/start.c:203:
more undefined references to `__stack_chk_guard' follow
collect2: error: ld returned 1 exit status
make: *** [Makefile:1766: u-boot] Error 1
I can get past this by either:
1.) Commenting out the `KBUILD_CFLAGS += $(call
cc-option,-mstack-protector-guard=global)` lines in the makefile
Or
2.) Changing "global" to "tls" in these lines.
Apparently these lines were introduced in the following commit:
$ git show 4072572b0f8
commit 4072572b0f8aeffedcd908dc45b7e046ee0554b0
Author: Christophe Leroy <christophe.le...@csgroup.eu>
Date: Wed Nov 15 19:36:36 2023 +0100
Fix stack-protector for powerpc
On powerpc, stack protector expects a function called
__stack_chk_fail_local() instead of __stack_chk_fail()
And some versions of GCC for powerpc default to TLS canary
instead of global canary, so always force GCC to use global
canary with -mstack-protector-guard=global
Is it possible that this change made with PowerPC in mind is problematic for
other architectures? I don't know if the sandbox build I'm going for targets,
say, an emulated CPU or if it targets the x86 CPU of the build machine. Or is
it more likely that a local change somewhere by a colleague is causing this?
Supporting this theory,
https://maskray.me/blog/2022-12-18-control-flow-integrity states:
"The canary is stored either in a libc global variable (__stack_chk_guard) or a
field in the thread
control block (e.g. %fs:40 on x86-64). Every architecture may have a preference
on the location. In
a glibc port, only one of -mstack-protector-guard=global and
-mstack-protector-guard=tls is
supported (BZ #26817)."
Thanks for any help,
Amy McLaughlin
