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

Potentially unclear explanation of register usage in chapter 4 - Becoming an elf lord #57

Open
oli-clive-griffin opened this issue Jan 8, 2024 · 0 comments

Comments

@oli-clive-griffin
Copy link

The kernel is almost ready to return from the syscall (remember, we’re still in execve). It pushes the argc, argv, and environment variables to the stack for the program to read when it begins.

The registers are now cleared. Before handling a syscall, the kernel stores the current value of registers to the stack to be restored when switching back to user space. Before returning to user space, the kernel zeroes this part of the stack.

Finally, the syscall is over and the kernel returns to userland. It restores the registers, which are now zeroed, and jumps to the stored instruction pointer. That instruction pointer is now the starting point of the new program (or the ELF interpreter) and the current process has been replaced!

When I first read this I was confused as to the order of operations. After a few reads I thought maybe it went like this

  1. execve starts
  2. register values copied onto stack
  3. execve almost finishing up
  4. register values copied back into registers
  5. memory that held those values is zeroed

I was going to open a PR correcting this but then realised I wasn't sure if I was right. Is it actually that the memory is zeroed and then zeroes are copied back into the registers? that didn't seem right to me ("It restores the registers, which are now zeroed")

Anyway, would love to be corrected!

P.S. thanks so much for these blog posts, they're awesome

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant