News for hackers. Stuff that matters.
Re:Tearing apart printf() (2018) by matheusmoreira on Tuesday November 12, 2019 @04:22PM (#21518307)
The registers rdi, rsi and rdx are acknowledged in the article but they don't appear in the disassembly:

  000000000040f9c0 <__libc_write>:
    40f9c0:  83 3d c5 bb 2a 00 00   cmpl   $0x0,0x2abbc5(%rip)  # 6bb58c <__libc_multiple_threads>
    40f9c7:  75 14                  jne    40f9dd <__write_nocancel+0x14>

  000000000040f9c9 <__write_nocancel>:
    40f9c9: b8 01 00 00 00        mov    $0x1,%eax
    40f9ce: 0f 05                 syscall
This is because they are set when the write function is called. The System V AMD64 ABI specifies that rdi, rsi and rdx are used for the 1st, 2nd and 3rd arguments of a function, perfectly matching the Linux system call ABI. The 5th and 6th also match: r8 and r9, respectively. However, the 4th argument doesn't match: system calls use r10 while System V uses rcx. I wish I knew why.
Re:Tearing apart printf() (2018) by gamozolabs on Tuesday November 12, 2019 @04:46PM (#21518513)
The x86 `syscall` instruction stores the return address into `rcx` as well as `RFLAGS` into `r11`. These are unconditionally clobbered and thus cannot be saved or used in a `syscall` transition.
Re:Tearing apart printf() (2018) by nitwit005 on Tuesday November 12, 2019 @06:15PM (#21519307)
Isn't that disassembly a replacement of the call to printf with a call to the write system call? Most compilers have the printf family as builtins to allow removing them from the code entirely: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
Re:Tearing apart printf() (2018) by saagarjha on Tuesday November 12, 2019 @06:51PM (#21519545)
Compilers will rarely inline all of printf in my experience.