syscall - En Linux, al ingresar una llamada al sistema, ¿cuál es el valor en% eax?(no orig_eax)

system call open linux

Question

Cuando devuelve un syscall, obtengo el valor de retorno de syscall en% eax, sin embargo, en la entrada obtengo -38, que es 0xFFFFFFDA en hexadecimal. Esto es para escribir / leer. ¿Cual es este numero? ¿Se puede usar para diferenciar de manera segura una entrada de una salida?

Answer 1

Todavía no entiendo cuando obtienes el -38 en eax, pero al hacer un syscall eax contiene un número que define el syscall (en un Kernel 2.6 puedes echar un vistazo a arch / x86 / include / asm / unistd_64.h para ver los números para cada llamada).

Entonces la secuencia es la siguiente:

1. tu programa
2. establecer eax a syscall (dep on call, también algunos otros regs)
3. init syscall (via int 0x80)
4. resultado de syscall en eax
5. su programa de nuevo

Tal vez su pregunta no esté formulada de esta manera, pero si no está escribiendo código / controlador kernel, la forma más fácil de decirlo, ya sea antes de la entrada de syscall o después de que syscall exit sea: TRUE cuando está en su código ;-). La entrada / salida en sí sucede (más o menos) instante en una instrucción, entonces o estás en el syscall (entonces lo sabrías porque debe ser algún código kernel o la llamada de bloqueo) o no (casi siempre cuando depuras tu codigo).

Answer 2

El -38 en eax en la entrada de syscall es aparentemente ENOSYS (Función no implementada), y syscall_trace_entry lo coloca allí en arch / x86 / kernel / entry_32.S. Supongo que es seguro suponer que siempre estará allí en la entrada de syscall, sin embargo , también puede estar allí en la salida de syscall , si el syscall devuelve ENOSYS.

Personalmente, siempre he seguido la pista de si estoy en la entrada o salida de syscall cuando uso ptrace, aunque también he visto algún código que depende de ENOSYS. (Supongo que está usando ptrace) Supongo que no funcionará si el proceso está dentro de un syscall cuando se conecta, pero he tenido la suerte de no toparme con ese problema.

Eché un vistazo rápido a las fuentes de datos, y supongo que también hace un seguimiento del estado, ya que hubo un comentario que decía: "Nos estamos uniendo a un proceso ya en marcha. Trate de descubrir el estado del proceso en las llamadas de sistema, para manejar el primer evento también ". y poco después dijo: "El proceso está dormido en medio de un syscall. Falsifique el evento de entrada de syscall".

En resumen, el valor no se puede usar con seguridad para diferenciar una entrada de una salida. Dicho esto, no estoy seguro de que el seguimiento sea el mejor método, ya que realmente no tengo ninguna fuente que definitivamente te diga que uses esa técnica, lo siento. :)