0

Out of curiosity how MacOS prepares its stack, I wrote an (x86_64) assembly program to print the top of the stack to stdout right when a process gets started:

global start
start:                      ; entry point of the binary, called by the loader
    push    rsp             ; push the stack pointer to stack so that we'll se that too
    mov     rdi, 1          ; file to write to: file descriptor 1 (STDOUT)
    lea     rsi, [rsp]      ; source of the write: stack
    mov     rdx, 64         ; number of bytes to write: 64 (8 x 64-bit integers)
    mov     rax, 0x02000004 ; MacOS syscall number for write
    syscall
    mov     rsi, [rsp+16]   ; smoke test: argv contents
    mov     rdx, 16         ; we expect the argv[0] ("./inspect_stack\0") to be 16 bytes long
    mov     rax, 0x02000004
    syscall
    mov     rsi, [rsp+32]   ; another smoke test: envp???
    mov     rdx, 11
    mov     rax, 0x02000004
    syscall
    mov     rax, 0x02000001 ; MacOS syscall number for exit
    syscall

Running this program and inspecting the output: nasm -f macho64 inspect_stack.asm && ld inspect_stack.o -static -o inspect_stack && ./inspect_stack | xxd -e -g 8 -c 8

I see something like this: (added some comments of my own)

00000000: 00007ff7bfeff6b0  ........  # this is the stack pointer we pushed
00000008: 0000000000000001  ........  # argc
00000010: 00007ff7bfeff880  ........  # argv; see the smoke test result
00000018: 0000000000000000  ........  # a null pointer???
00000020: 00007ff7bfeff890  ........  # are these part of envp?
00000028: 00007ff7bfeff89f  ........  # ...seems like an array of pointers stored inline?
00000030: 00007ff7bfeff8dc  ........  # ...and they seem to point at a continuous buffer
00000038: 00007ff7bfeff8ed  ........
00000040: 636570736e692f2e  ./inspec  # the result of the 1st smoke test. yes, argv[0]!
00000048: 006b636174735f74  t_stack.
00000050: 6573552f3d445750  PWD=/Use  # the result of the 2nd smoke test... seems like envp?
00000058:           2f7372  rs/

So, I had an understanding that there would be a 64-bit integer (argc) and two pointers (to argv and to envp) stored to the stack at the start of the program. However, this doesn't seem to be true, or then the envp pointer is null for some reason. However, we can see that the envp array, stored inline, seemingly starts after the null. What's the actual layout of the stack when the process starts?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
GolDDranks
  • 3,272
  • 4
  • 22
  • 30

1 Answers1

2

Inspecting a bit more, and adding more arguments, I noticed that my understanding that there would be two pointers to argv and envp at the top of the stack, was mistaken. Instead, argv and envp are stored inline, as arrays of pointers to the associated strings. Both arrays are null-terminated, so the null value I was seeing was actually the terminator of argv. Adding more arguments makes this a lot clearer: nasm -f macho64 inspect_stack.asm && ld inspect_stack.o -static -o inspect_stack && ./inspect_stack first second | xxd -e -g 8 -c 8

00000000: 00007ff7bfeff698  ........
00000008: 0000000000000003  ........  # argc
00000010: 00007ff7bfeff878  x.......  # argv[0]
00000018: 00007ff7bfeff888  ........  # argv[1]
00000020: 00007ff7bfeff88e  ........  # argv[2]
00000028: 0000000000000000  ........  # argv end
00000030: 00007ff7bfeff895  ........  # envp[0]
00000038: 00007ff7bfeff8a4  ........  # envp[1] and so on
00000040: 636570736e692f2e  ./inspec
00000048: 006b636174735f74  t_stack.
00000050: 5000646e6f636573  second.P  # the second smoke test now sees argv[2]!
00000058:           3d4457  WD=       # seems that the envp strings are located right after argc strings

TL;DR: I thought that the second and third 64-bit values in the stack were char **argv and char **envp. Instead, they were argv[0] and argv[1]. Now, to get char **argv that C main would expect I could take [rsp + 8] (8 bytes for skipping argc), and to get char **envp I could mov rax, [rsp] and then take [rsp + 8 + rax*8 + 8] (8 bytes for skipping argc, then skipping argc number of pointers, and finally another 8 bytes for skipping the null terminator).

GolDDranks
  • 3,272
  • 4
  • 22
  • 30
  • 1
    Yup, this matches the x86-64 System V ABI, same as on Linux. [How Get arguments value using inline assembly in C without Glibc?](https://stackoverflow.com/a/50261564) quotes some docs with a layout table. It's common to `pop reg` to read `argc`, although that misaligns the stack which started out aligned by 16. – Peter Cordes Mar 18 '22 at 18:38
  • Do you have any idea why this is the case? Are people aligning the stack anyway, just in case? (In which case popping it before doesn't matter?) – GolDDranks Mar 18 '22 at 18:41
  • I also noticed that it's common to zero ebp, although in my tests it always starts out zeroed? Is this a portability thing? (The zeroing not being guaranteed etc.?) – GolDDranks Mar 18 '22 at 18:42
  • I mean it's common in toy programs that only make raw system calls, and don't care about 16-byte stack alignment. If you do eventually want to call C-compiler-generated code, you might just `mov edi, [rsp]` and LEA argv and envp. – Peter Cordes Mar 18 '22 at 18:43
  • 1
    In Linux, RBP (and other regs) start out zeroed when entering user-space from the kernel in a fresh process. So it's zero at the top of `_start` *in a static executable*. In a dynamically-linked executable, ld.so's code will have run first (the kernel starts execution there, at the `_start` of the ELF interpreter) and left garbage in registers except for RSP and RDX (the atexit callback) by the time the main executable's `_start` is reached. I don't know MacOS process startup / dynamic linking details. – Peter Cordes Mar 18 '22 at 18:46