Subject: stack smashing protection?

From: "Jim Pryor" <[email-masked]>
Date: Tue, 18 Mar 2025 16:59:47 -0400

I'm building some binaries on an ARMv7 build of Alpine, and getting errors about the symbol `__stack_chk_fail` being missing.

Adding `-fno-stack-protector` to my build command solves the issue.

But I wonder if there's a way to get stack protection? I notice that when I do `nm -D /usr/lib/libc.so | grep __stack_chk_fail` I get the output:

```
0003cc48 T __stack_chk_fail
```

So the symbol is there, just not getting linked.

I tried adding each of these to my build command, but none of them seemed to fix the issue (that is, let me build without disabling stack protection):

* -Wl,--whole-archive -lssp_nonshared -Wl,--no-whole-archive
* -static-libgcc
* -Wl,--as-needed -lc

Is there something else I should be trying?

-- 
[email-masked]

---

From: "Sertonix" <[email-masked]>
Date: Tue, 18 Mar 2025 21:43:00 +0000

> Is there something else I should be trying?

Do you have any small command that can reproduce the issue?

I tried gcc -o main main.c -fstack-protector-all with a simple test file
and it build fine.

---

From: "Jim Pryor" <[email-masked]>
Date: Tue, 18 Mar 2025 18:30:56 -0400

> I tried gcc -o main main.c -fstack-protector-all with a simple test file

Unfortunately I don't have a minimal reproduction. For me the failure came when building the examples/features2 and examples/features3 files in the micropython source tree. This requires having a significant part of the micropython source tree installed (for included headers and makefile pieces). Also the linking is done by the tools/mpy_ld.py file, which uses CPython and the py3-elftools library. So a whole lot of infrastructure. I expect there'd be some way to get a smaller reproduction, but I'm not able to produce it now.

I can build the other example Python C libraries (which the mpy_ld.py tool links into *.mpy files) besides those two, without disabling stack protection. And if I disable stack protection I can build all of them.

-- 
[email-masked]

---

From: "Jim Pryor" <[email-masked]>
Date: Tue, 18 Mar 2025 19:00:00 -0400

I realized that it's not surprising that the alternative fixes I mentioned aren't working, since supplying them to the gcc build command isn't going to pass them on to the non-standard linker (the mpy_ld.py script) used in this case. And that tool doesn't have command-line options that look promising. I can hack its source directly though.

The missing symbol is found in the /usr/lib/libc.so file (well, that's a link, but it's found in its target). But that doesn't seem to be linked into the binary that's produced.

There is a /usr/lib/libc.a file. I can look into whether some *.o file extractable from that defines the symbol I'm missing...

-- 
[email-masked]

---

From: "Jim Pryor" <[email-masked]>
Date: Tue, 18 Mar 2025 19:12:19 -0400

On Tue, Mar 18, 2025, at 7:00 PM, Jim Pryor wrote:
> There is a /usr/lib/libc.a file. I can look into whether some *.o file 
> extractable from that defines the symbol I'm missing...

If I extract the __stack_chk_fail.lo file from that archive (and also the memcpy.lo file, which it in turn needs a symbol from) and add those two object files along with the project's binaries, then linking works ok and the generated *.mpy library seems to work.

-- 
[email-masked]