Może szukasz ABI x86_64?

• www.x86-64.org/documentation/abi.pdf (404 w 2018-11-24)
• www.x86-64.org/documentation/abi.pdf w 2018 roku, w 2018 roku, w 2018 roku, w 2019 roku, w 2019 roku, w 2019 roku, w 2019 roku]}
• gdzie jest udokumentowany system x86 - 64 V ABI? - https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI jest na bieżąco (przez HJ Lu, jednego z opiekunów ABI) z linkami do plików PDF z oficjalnej obecnej wersji.

Jeśli nie jest to dokładnie to, czego szukasz, użyj "x86_64 abi" w preferowanej wyszukiwarce, aby znaleźć alternatywne odniesienia.

Konwencje wywołania definiują sposób przekazywania parametrów w rejestrach podczas wywoływania lub wywoływania przez inny program. A najlepszym źródłem tej konwencji są standardy ABI zdefiniowane dla każdego z tych urządzeń. Dla ułatwienia kompilacji, ten sam ABI jest również używany przez program userspace i kernel. Linux / Freebsd podąża za tym samym ABI dla x86-64 i innym zestawem dla 32-bitów. Ale x86-64 ABI Dla Windows różni się od Linuksa / FreeBSD. I generalnie ABI nie rozróżnia wywołanie systemowe vs zwykłe "wywołania funkcji". Ie, oto szczególny przykład wywoływania konwencji x86_64 i jest to takie samo zarówno dla przestrzeni użytkownika Linuksa, jak i jądra: http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/ (zwróć uwagę na ciąg A,b,c,D,e, f parametrów):

Wydajność jest jedną z przyczyn tych ABI (np. przekazywanie parametrów przez rejestry zamiast zapisywania do stosów pamięci)

Dla ARM istnieje wiele ABI:

Http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html

Https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/iPhoneOSABIReference.pdf

Konwencja ARM64:

Http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf

Dla Linuksa na PowerPC:

Http://refspecs.freestandards.org/elf/elfspec_ppc.pdf

Http://www.0x04.net/doc/elf/psABI-ppc64.pdf

I dla osadzonych jest PPC EABI:

Http://www.freescale.com/files/32bit/doc/app_note/PPCEABI.pdf

Ten dokument jest dobrym przeglądem wszystkich różnych konwencji:

Http://www.agner.org/optimize/calling_conventions.pdf

Linux kernel 5.0 komentarze źródłowe

Wiedziałem, że szczegóły x86 są Pod arch/x86, a te sprawy syscall idą pod arch/x86/entry. Tak więc szybki git grep rdi w tym katalogu prowadzi mnie do arch / x86 / entry / entry_64.S :

/*
 * 64-bit SYSCALL instruction entry. Up to 6 arguments in registers.
 *
 * This is the only entry point used for 64-bit system calls.  The
 * hardware interface is reasonably well designed and the register to
 * argument mapping Linux uses fits well with the registers that are
 * available when SYSCALL is used.
 *
 * SYSCALL instructions can be found inlined in libc implementations as
 * well as some other programs and libraries.  There are also a handful
 * of SYSCALL instructions in the vDSO used, for example, as a
 * clock_gettimeofday fallback.
 *
 * 64-bit SYSCALL saves rip to rcx, clears rflags.RF, then saves rflags to r11,
 * then loads new ss, cs, and rip from previously programmed MSRs.
 * rflags gets masked by a value from another MSR (so CLD and CLAC
 * are not needed). SYSCALL does not save anything on the stack
 * and does not change rsp.
 *
 * Registers on entry:
 * rax  system call number
 * rcx  return address
 * r11  saved rflags (note: r11 is callee-clobbered register in C ABI)
 * rdi  arg0
 * rsi  arg1
 * rdx  arg2
 * r10  arg3 (needs to be moved to rcx to conform to C ABI)
 * r8   arg4
 * r9   arg5
 * (note: r12-r15, rbp, rbx are callee-preserved in C ABI)
 *
 * Only called from user space.
 *
 * When user can change pt_regs->foo always force IRET. That is because
 * it deals with uncanonical addresses better. SYSRET has trouble
 * with them due to bugs in both AMD and Intel CPUs.
 */

I dla 32-bitowych w arch / x86 / entry / entry_32.S :

/*
 * 32-bit SYSENTER entry.
 *
 * 32-bit system calls through the vDSO's __kernel_vsyscall enter here
 * if X86_FEATURE_SEP is available.  This is the preferred system call
 * entry on 32-bit systems.
 *
 * The SYSENTER instruction, in principle, should *only* occur in the
 * vDSO.  In practice, a small number of Android devices were shipped
 * with a copy of Bionic that inlined a SYSENTER instruction.  This
 * never happened in any of Google's Bionic versions -- it only happened
 * in a narrow range of Intel-provided versions.
 *
 * SYSENTER loads SS, ESP, CS, and EIP from previously programmed MSRs.
 * IF and VM in RFLAGS are cleared (IOW: interrupts are off).
 * SYSENTER does not save anything on the stack,
 * and does not save old EIP (!!!), ESP, or EFLAGS.
 *
 * To avoid losing track of EFLAGS.VM (and thus potentially corrupting
 * user and/or vm86 state), we explicitly disable the SYSENTER
 * instruction in vm86 mode by reprogramming the MSRs.
 *
 * Arguments:
 * eax  system call number
 * ebx  arg1
 * ecx  arg2
 * edx  arg3
 * esi  arg4
 * edi  arg5
 * ebp  user stack
 * 0(%ebp) arg6
 */

Glibc 2.29 Linux x86_64 implementacja wywołań systemowych

Teraz oszukujmy patrząc na główne implementacje libc i zobaczmy czym one są robiąc.

Co może być lepszego niż przeglądanie glibc, którego teraz używam podczas pisania tej odpowiedzi? :-)

Glibc 2.29 definiuje syscalls x86_64 na sysdeps/unix/sysv/linux/x86_64/sysdep.h i zawiera jakiś ciekawy kod, np.:

/* The Linux/x86-64 kernel expects the system call parameters in
   registers according to the following table:

    syscall number  rax
    arg 1       rdi
    arg 2       rsi
    arg 3       rdx
    arg 4       r10
    arg 5       r8
    arg 6       r9

    The Linux kernel uses and destroys internally these registers:
    return address from
    syscall     rcx
    eflags from syscall r11

    Normal function call, including calls to the system call stub
    functions in the libc, get the first six parameters passed in
    registers and the seventh parameter and later on the stack.  The
    register use is as follows:

     system call number in the DO_CALL macro
     arg 1      rdi
     arg 2      rsi
     arg 3      rdx
     arg 4      rcx
     arg 5      r8
     arg 6      r9

    We have to take care that the stack is aligned to 16 bytes.  When
    called the stack is not aligned since the return address has just
    been pushed.


    Syscalls of more than 6 arguments are not supported.  */

I:

/* Registers clobbered by syscall.  */
# define REGISTERS_CLOBBERED_BY_SYSCALL "cc", "r11", "cx"

#undef internal_syscall6
#define internal_syscall6(number, err, arg1, arg2, arg3, arg4, arg5, arg6) \
({                                  \
    unsigned long int resultvar;                    \
    TYPEFY (arg6, __arg6) = ARGIFY (arg6);              \
    TYPEFY (arg5, __arg5) = ARGIFY (arg5);              \
    TYPEFY (arg4, __arg4) = ARGIFY (arg4);              \
    TYPEFY (arg3, __arg3) = ARGIFY (arg3);              \
    TYPEFY (arg2, __arg2) = ARGIFY (arg2);              \
    TYPEFY (arg1, __arg1) = ARGIFY (arg1);              \
    register TYPEFY (arg6, _a6) asm ("r9") = __arg6;            \
    register TYPEFY (arg5, _a5) asm ("r8") = __arg5;            \
    register TYPEFY (arg4, _a4) asm ("r10") = __arg4;           \
    register TYPEFY (arg3, _a3) asm ("rdx") = __arg3;           \
    register TYPEFY (arg2, _a2) asm ("rsi") = __arg2;           \
    register TYPEFY (arg1, _a1) asm ("rdi") = __arg1;           \
    asm volatile (                          \
    "syscall\n\t"                           \
    : "=a" (resultvar)                          \
    : "0" (number), "r" (_a1), "r" (_a2), "r" (_a3), "r" (_a4),     \
      "r" (_a5), "r" (_a6)                      \
    : "memory", REGISTERS_CLOBBERED_BY_SYSCALL);            \
    (long int) resultvar;                       \
})

Szybkie przypomnienie clobbers:

• cc oznacza rejestry flagi. Ale [45]} Peter Cordes komentuje że jest to niepotrzebne tutaj.
• memory oznacza, że wskaźnik może być przekazany w assembly i użyty do uzyskania dostępu do pamięci

Aby uzyskać jednoznaczny, minimalny przykład od podstaw, zobacz odpowiedź: Jak wywołać wywołanie systemowe przez syscall lub sysenter in inline assembly?

Aby niektóre syscalls w montażu ręcznie

Niezbyt naukowe, ale zabawne:

• X86_64.S

  .text
  .global _start
  _start:
  asm_main_after_prologue:
      /* write */
      mov $1, %rax    /* syscall number */
      mov $1, %rdi    /* stdout */
      mov $msg, %rsi  /* buffer */
      mov $len, %rdx  /* len */
      syscall
  
      /* exit */
      mov $60, %rax   /* syscall number */
      mov $0, %rdi    /* exit status */
      syscall
  msg:
      .ascii "hello\n"
  len = . - msg
  

  GitHub upstream .

Wykonywanie wywołań systemowych z C

Oto przykład z ograniczeniami rejestru: jak wywołać wywołanie systemowe przez syscall lub sysenter w wbudowanym zestawie?

Aarch64

Pokazałem minimum przykład runnable userland na: https://reverseengineering.stackexchange.com/questions/16917/arm64-syscalls-table/18834#18834 TODO grep kernel kod tutaj, powinno być łatwe.