-fstack-protector-strong with no libc, segfault on a %fs load at 0x28

Beginner here (so grain of salt), but I thought the default guard location was the plain global and TLS was the opt-in? Does -mstack-protector-guard=global make your __stack_chk_guard get used instead of %fs:0x28?

Kiln, you've got it the wrong way round for x86-64 Linux. The default is the TLS canary, read from %fs:0x28, and the plain global is the thing you have to ask for. That also explains my fault address exactly: _start never sets the FS base, so it's zero and the load lands on 0x28. My __stack_chk_guard was never going to be read, it's just a symbol sitting there.

There are two ways out, and I'm going with the first.

1. Tell the compiler to use the global, with -mstack-protector-guard=global, and on top of that -mstack-protector-guard-symbol=__stack_chk_guard so it names mine. Nothing at runtime needs setting up.
2. Leave the default and do it by hand: reserve a zeroed block of 64 bytes or so, put the canary at offset 0x28, point FS at it with prctl(ARCH_SET_FS, ...) before the first protected function runs. _start itself has to be compiled without the protector, or it faults before it gets there.

The second is more faithful to what glibc does, but for a hex dumper it's a lot of ceremony for one 8-byte value.

Ok, so the FS base is zero, which makes sense now (cheers). Why 0x28 specifically, is that just where glibc's thread header keeps it?

Pretty much, yeah. On x86-64 glibc, %fs points at the thread control block, and the start of that struct goes roughly like this:

• 0x00: tcb pointer (points at itself)
• 0x08: dtv
• 0x10: self pointer
• 0x18: multiple_threads (int), then gscope_flag (int) at 0x1c
• 0x20: sysinfo
• 0x28: stack_guard

So 0x28 is just where the canary landed in that layout. GCC hardcodes %fs:0x28 because the x86-64 ABI docs pin it down, as I remember it, which is why every libc has to put it there. That's also why lathe's second option works: all you need is a block with 8 bytes at 0x28 and FS pointing at it, so nothing else in the header matters.

Thanks for asking, by the way, I had to look at the struct again myself to be sure of the order. The other offsets only matter if something reads them, though.

on a load through %fs that I didn't write, fault address 0x28

Got this exact crash in my uni project too.

Following up on my own fix, since there's a catch with option 1 that I skipped over.

It stops the %fs load, but the canary is now whatever constant sits in the source, so it's identical on every run and in every binary. For a hex dumper that's harmless, but it isn't much of a protector. If you want it to be real, the kernel hands you 16 random bytes at AT_RANDOM in the auxiliary vector. In _start, step past argv and the envp NULL, walk the auxv pairs until you hit type 25, and copy 8 bytes from that pointer into __stack_chk_guard before calling hexd_main. _start has to stay unprotected, as with option 2, and the copy must happen before any protected function is entered, otherwise the prologue stores the old value and the epilogue compares against the new one, which fails.

To check the compiler has really stopped touching FS:

objdump -d hexd | grep '%fs'

That should come back empty. If something still shows up, it's usually an object built without the guard flags, so check that every file in the link gets the same CFLAGS.

On option 2, the syscall number you want for the FS base is 158 on x86-64.