Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: compiled binaries set PT_GNU_STACK alignment to 2**3 on amd64 #12013

Closed
m4b opened this issue Aug 4, 2015 · 4 comments
Closed

cmd/link: compiled binaries set PT_GNU_STACK alignment to 2**3 on amd64 #12013

m4b opened this issue Aug 4, 2015 · 4 comments

Comments

@m4b
Copy link

m4b commented Aug 4, 2015

Apologies ahead of time if this issue is raised in the wrong spot; the golang/tools repo is only a mirror, and couldn't raise it there, where I suspect it belongs.

Issue

I was scanning all of my binaries in /usr/lib and my program noticed the binary at /usr/lib/go/pkg/tool/linux_amd64/cgo seems to have an invalid or unknown program header.

objdump verifies this issue as well. Here is its output:

$ objdump -p /usr/lib/go/pkg/tool/linux_amd64/cgo

/usr/lib/go/pkg/tool/linux_amd64/cgo:     file format elf64-x86-64

Program Header:
    PHDR off    0x0000000000000040 vaddr 0x0000000000400040 paddr 0x0000000000400040 align 2**12
         filesz 0x0000000000000150 memsz 0x0000000000000150 flags r-x
    LOAD off    0x0000000000000040 vaddr 0x0000000000400040 paddr 0x0000000000400040 align 2**12
         filesz 0x0000000000122856 memsz 0x0000000000122856 flags r-x
    LOAD off    0x0000000000123000 vaddr 0x0000000000523000 paddr 0x0000000000523000 align 2**12
         filesz 0x000000000024e959 memsz 0x000000000024e959 flags r--
    LOAD off    0x0000000000372000 vaddr 0x0000000000772000 paddr 0x0000000000772000 align 2**12
         filesz 0x0000000000016d00 memsz 0x0000000000034f18 flags rw-
   STACK off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-
0x65041580 off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags --- 2a00

If I had to guess, I'd say perhaps the 2nd to last program header, STACK, has an incorrect alignment (2³ instead of 2⁴ which you normally see in programs), and this might be bleeding over into the next program header. It's hard to say though, obviously.

Affected platforms

I've only checked on the following linux systems:

  • 64-bit archlinux
  • 64-bit Ubuntu 14.10
@mdempsky
Copy link
Member

mdempsky commented Aug 4, 2015

/cc @ianlancetaylor

I don't think this is specific to the cgo binary. I see this for all Go executables on my Ubuntu 14.04 amd64 machine. However, I also see it for about 20% of executables in /usr/bin.

What exactly is the consequence of this? I can't find any documented significance to the alignment field of PT_GNU_STACK. Glibc only seems to care about the flags field.

@mdempsky mdempsky changed the title cgo compiled binary has invalid ELF program header cmd/link: compiled binaries set PT_GNU_STACK alignment to 2**3 on amd64 Aug 4, 2015
@m4b
Copy link
Author

m4b commented Aug 4, 2015

@mdempsky yea I'm not sure what alignment does 😁 in the dynamic loader, or its significance either, as I can't seem to find any documentation either. My guess is it's "documented" in the source code for the dynamic linker.

However, I'm not sure I'd have changed the title, since the issue was specifically about the last program header being bad (unless you think the alignment is the cause of the malformed final header), e.g.:

0x65041580 off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3 filesz 0x0000000000000000 memsz 0x0000000000000000 flags --- 2a00

is not a valid header; not only is the program header name unknown, it's flags are nill, and it has '2a00' after flags, which is probably an artifact of objdump not understanding the ph.

@mdempsky
Copy link
Member

mdempsky commented Aug 4, 2015

Oh, that's the PT_PAX_FLAGS header, and it's working as intended. Just objdump doesn't know its name.

@mdempsky mdempsky closed this as completed Aug 4, 2015
@m4b
Copy link
Author

m4b commented Aug 4, 2015

Ah, apologies, sorry for wasting your time.

@golang golang locked and limited conversation to collaborators Aug 5, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants