Los siguientes enlaces explican las convenciones de llamadas al sistema x86-32 tanto para UNIX (sabor BSD) como para Linux:

• http://www.int80h.org/bsdasm/#system-calls

• http://www.freebsd.org/doc/en/books/developers-handbook/x86-system-calls.html

Pero, ¿cuáles son las convenciones de llamadas al sistema x86-64 en UNIX y Linux?

Lectura adicional para cualquiera de los temas aquí: La guía definitiva para las llamadas al sistema Linux

Verifiqué esto usando GNU Assembler (gas) en Linux.

Interfaz de kernel

x86-32 también conocido como i386 Linux System Call Convention:

En x86-32, los parámetros para la llamada al sistema Linux se pasan mediante registros. %eaxpara syscall_number. % ebx,% ecx,% edx,% esi,% edi,% ebp se utilizan para pasar 6 parámetros a las llamadas del sistema.

El valor de retorno está en %eax. Todos los demás registros (incluidos los EFLAGS) se conservan en todo el int $0x80.

Tomé el siguiente fragmento del Tutorial de ensamblaje de Linux, pero tengo dudas al respecto. Si alguien puede mostrar un ejemplo, sería genial.

Si hay más de seis argumentos, %ebxdebe contener la ubicación de la memoria donde se almacena la lista de argumentos, pero no se preocupe por esto porque es poco probable que use una llamada al sistema con más de seis argumentos.

Para ver un ejemplo y un poco más de lectura, consulte http://www.int80h.org/bsdasm/#alternate-calling-convention . Otro ejemplo de Hello World para i386 Linux usando int 0x80: Hola, ¿mundo en lenguaje ensamblador con llamadas al sistema Linux?

Hay una forma más rápida de hacer llamadas al sistema de 32 bits: usando sysenter. El núcleo mapea una página de memoria en cada proceso (el vDSO), con el lado del espacio de usuario de la sysenterdanza, que tiene que cooperar con el núcleo para que pueda encontrar la dirección de retorno. Arg para registrar la asignación es lo mismo que para int $0x80. Normalmente debería llamar al vDSO en lugar de usarlo sysenterdirectamente. (Consulte la Guía definitiva para las llamadas al sistema Linux para obtener información sobre cómo vincular y llamar al vDSO, y para obtener más información sysentery todo lo demás relacionado con las llamadas al sistema).

x86-32 [Gratis | Abrir | Red | DragonFly] Convención del sistema BSD UNIX:

Los parámetros se pasan en la pila. Empuje los parámetros (último parámetro empujado primero) en la pila. Luego inserte una información ficticia adicional de 32 bits (en realidad no son datos ficticios. Consulte el siguiente enlace para obtener más información) y luego brinde una instrucción de llamada al sistemaint $0x80

http://www.int80h.org/bsdasm/#default-calling-convention

x86-64 Convención de llamada al sistema Linux:

x86-64 Mac OS X es similar pero diferente . TODO: comprueba lo que * BSD hace.

Consulte la sección: "A.2 Convenciones del kernel de Linux AMD64 " de la interfaz binaria del sistema V Suplemento del procesador de arquitectura AMD64 . Las últimas versiones de las psABI i386 y x86-64 System V se pueden encontrar enlazadas desde esta página en el repositorio del mantenedor de ABI . (Ver también elx86 etiqueta wiki para enlaces ABI actualizados y muchas otras cosas buenas sobre x86 asm.)

Aquí está el fragmento de esta sección:

1. Las aplicaciones de nivel de usuario se utilizan como registros enteros para pasar la secuencia% rdi,% rsi,% rdx,% rcx,% r8 y% r9. La interfaz del kernel utiliza% rdi,% rsi,% rdx,% r10,% r8 y% r9.
2. Una llamada al sistema se realiza a través de las syscallinstrucciones . Este clobbers% rcx y% r11 , así como el valor de retorno% rax, pero se conservan otros registros.
3. El número de la llamada al sistema debe pasarse en el registro% rax.
4. Las llamadas al sistema están limitadas a seis argumentos, no se pasa ningún argumento directamente en la pila.
5. Al regresar de la llamada al sistema, el registro% rax contiene el resultado de la llamada al sistema. Un valor en el rango entre -4095 y -1 indica un error, lo es -errno.
6. Solo los valores de la clase INTEGER o de la clase MEMORY se pasan al kernel.

Recuerde que esto es del apéndice específico de Linux al ABI, e incluso para Linux es informativo, no normativo. (Pero de hecho es exacto).

Este int $0x80ABI de 32 bits se puede usar en código de 64 bits (pero no se recomienda). ¿Qué sucede si usa la ABI de Linux int 0x80 de 32 bits en código de 64 bits? Todavía trunca sus entradas a 32 bits, por lo que no es adecuado para punteros, y pone a cero r8-r11.

Interfaz de usuario: función de llamada

Convención de llamada a funciones x86-32:

En x86-32 los parámetros se pasaron en la pila. El último parámetro se introdujo primero en la pila hasta que se hayan completado todos los parámetros y luego callse haya ejecutado la instrucción. Esto se usa para llamar a las funciones de la biblioteca C (libc) en Linux desde el ensamblado.

Las versiones modernas del i386 System V ABI (utilizado en Linux) requieren una alineación de 16 bytes %espantes de a call, como siempre ha requerido el x86-64 System V ABI. Los Callees pueden asumir eso y usar cargas / almacenes SSE de 16 bytes que fallan sin alinearse. Pero históricamente, Linux solo requería una alineación de pila de 4 bytes, por lo que se requería un trabajo adicional para reservar espacio alineado naturalmente incluso para un byte de 8 bytes doubleo algo así.

Algunos otros sistemas modernos de 32 bits aún no requieren una alineación de pila de más de 4 bytes.

x86-64 Convención de llamada a la función de espacio de usuario del sistema V:

x86-64 System V pasa args en registros, que es más eficiente que la convención de args de pila de i386 System V. Evita la latencia y las instrucciones adicionales de almacenar los argumentos en la memoria (caché) y luego volver a cargarlos en la persona que llama. Esto funciona bien porque hay más registros disponibles y es mejor para las CPU modernas de alto rendimiento donde la latencia y la ejecución fuera de orden son importantes. (El i386 ABI es muy antiguo).

En este nuevo mecanismo: Primero, los parámetros se dividen en clases. La clase de cada parámetro determina la manera en que se pasa a la función llamada.

Para obtener información completa, consulte: "3.2 Secuencia de llamada de función" de la interfaz binaria de la aplicación System V AMD64 Architecture Processor Supplement que lee, en parte:

Una vez que se clasifican los argumentos, los registros se asignan (en orden de izquierda a derecha) para pasar de la siguiente manera:

1. Si la clase es MEMORY, pase el argumento en la pila.
2. Si la clase es INTEGER, se utiliza el siguiente registro disponible de la secuencia% rdi,% rsi,% rdx,% rcx,% r8 y% r9

También lo %rdi, %rsi, %rdx, %rcx, %r8 and %r9son los registros en orden utilizados para pasar parámetros de entero / puntero (es decir, clase INTEGER) a cualquier función libc desde el ensamblado. % rdi se usa para el primer parámetro INTEGER. % rsi para el segundo,% rdx para el tercero y así sucesivamente. Entonces se calldeben dar instrucciones. La pila ( %rsp) debe estar alineada con 16B cuando se callejecuta.

Si hay más de 6 parámetros INTEGER, el séptimo parámetro INTEGER y más tarde se pasan a la pila. (La persona que llama aparece, igual que x86-32.)

Los primeros 8 argumentos de coma flotante se pasan en% xmm0-7, más tarde en la pila. No hay registros de vector de llamada preservada. (Una función con una combinación de FP y argumentos enteros puede tener más de 8 argumentos de registro total).

Las funciones variables ( comoprintf ) siempre necesitan %al= el número de argumentos de registro FP.

Hay reglas sobre cuándo empacar estructuras en registros ( rdx:raxal regreso) vs. en memoria. Consulte la ABI para obtener detalles y verifique la salida del compilador para asegurarse de que su código concuerde con los compiladores sobre cómo se debe pasar / devolver algo.

Tenga en cuenta que la convención de llamada de función x64 de Windows tiene múltiples diferencias significativas con respecto al Sistema x86-64 V, como el espacio de sombra que debe ser reservado por la persona que llama (en lugar de una zona roja) y xmm6-xmm15 con llamada preservada. Y reglas muy diferentes para qué argumento va en qué registro.

¿Quizás estás buscando el x86_64 ABI?

• www.x86-64.org/documentation/abi.pdf (404 en 2018-11-24)
• www.x86-64.org/documentation/abi.pdf (a través de Wayback Machine en 2018-11-24)
• ¿Dónde está documentado el x86-64 System V ABI? - https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI se mantiene actualizado (por HJ Lu, uno de los mantenedores de ABI) con enlaces a archivos PDF de la versión actual oficial.

Si eso no es exactamente lo que busca, use 'x86_64 abi' en su motor de búsqueda preferido para encontrar referencias alternativas.

Las convenciones de llamada definen cómo se pasan los parámetros en los registros al llamar o ser llamado por otro programa. Y la mejor fuente de estas convenciones es en forma de estándares ABI definidos para cada uno de estos hardware. Para facilitar la compilación, el mismo espacio de usuario también es utilizado por el espacio de usuario y el programa del núcleo. Linux / Freebsd sigue el mismo ABI para x86-64 y otro conjunto para 32 bits. Pero x86-64 ABI para Windows es diferente de Linux / FreeBSD. Y, en general, ABI no diferencia la llamada del sistema frente a las "llamadas de funciones" normales. Es decir, aquí hay un ejemplo particular de convenciones de llamadas x86_64 y es lo mismo para el espacio de usuario de Linux y el núcleo: http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64 / (tenga en cuenta la secuencia a, b, c, d, e, f de parámetros):

El rendimiento es una de las razones de estos ABI (por ejemplo, pasar parámetros a través de registros en lugar de guardarlos en pilas de memoria)

Para ARM hay varios 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

Convención ARM64:

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

Para Linux en PowerPC:

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

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

Y para incrustado está el PPC EABI:

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

Este documento es una buena descripción de todas las diferentes convenciones:

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

Comentarios de fuente del kernel 5.0 de Linux

Sabía que los detalles de x86 están por debajo arch/x86, y que las cosas de syscall se hunden arch/x86/entry. Entonces, un rápido git grep rdien ese directorio me lleva a 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.
 */

y para 32 bits en 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
 */

Implementación de llamada al sistema glibc 2.29 Linux x86_64

Ahora hagamos trampa mirando las principales implementaciones de libc y veamos qué están haciendo.

¿Qué podría ser mejor que mirar glibc que estoy usando ahora mientras escribo esta respuesta? :-)

glibc 2.29 define x86_64 syscalls en sysdeps/unix/sysv/linux/x86_64/sysdep.hy que contiene algún código interesante, por ejemplo:

/* 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.  */

y:

/* 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;                       \
})

que creo que se explican por sí mismas. Observe cómo esto parece haber sido diseñado para coincidir exactamente con la convención de llamada de las funciones regulares ABI AMD64 de System V: https://en.wikipedia.org/wiki/X86_calling_conventions#List_of_x86_calling_conventions

Recordatorio rápido de los clobbers:

• ccsignifica registros de bandera. Pero Peter Cordes comenta que esto es innecesario aquí.
• memory significa que se puede pasar un puntero en el ensamblaje y usarlo para acceder a la memoria

Para obtener un ejemplo explícito mínimo ejecutable desde cero, vea esta respuesta: ¿Cómo invocar una llamada del sistema a través del sysenter en el ensamblaje en línea?

Hacer algunas llamadas de sistema en ensamblaje manualmente

No muy científico, pero divertido:

• 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 aguas arriba .

aarch64

He mostrado un ejemplo de tierra de usuario mínima ejecutable en: /reverseengineering/16917/arm64-syscalls-table/18834#18834 TODO el código de kernel grep aquí, debería ser fácil.