¿Es esta una buena manera de interceptar las llamadas al sistema?

Question

Estoy escribiendo una herramienta. Una parte de esa herramienta será su capacidad para registrar los parámetros de las llamadas al sistema. Bien, puedo usar ptrace para ese propósito, pero ptrace es bastante lento. Un método más rápido que se me ocurrió fue modificar el glibc. Pero esto se está poniendo difícil, ya que gcc inserta mágicamente sus propias funciones integradas como envoltorios de llamadas al sistema que usando el código definido en glibc. Usar -fno-builtin tampoco ayuda en eso.

Así que se me ocurrió la idea de escribir una biblioteca compartida, que incluye cada contenedor de llamadas del sistema, como mmap y luego realizar el registro antes de llamar a la función de conteo de llamadas del sistema. Por ejemplo, el pseudo código de cómo se vería mi mmap se da a continuación.

int mmap(...) 
{ 
log_parameters(...); 
call_original_mmap(...); 
... 
} 

Luego puedo usar LD_PRELOAD para cargar esta biblioteca primero. ¿Crees que esta idea funcionará o me falta algo?

Answer 1

Todas las llamadas al sistema desde el espacio de usuario pasan por un controlador de interrupción para cambiar al modo núcleo, si encuentra este controlador probablemente pueda agregar algo allí.

EDIT He encontrado este http://cateee.net/lkddb/web-lkddb/AUDITSYSCALL.html. Núcleos Linux: 2.6.6-2.6.39, 3.0-3.4 tienen soporte para la auditoría de llamadas del sistema. Este es un módulo kernel que debe estar habilitado. Tal vez pueda ver la fuente de este módulo si no es confuso.

Answer 2

Como han mencionado otros, si el binario está enlazado estáticamente, el enlazador dinámico omitirá cualquier intento de interceptar funciones usando libdl. En su lugar, debería considerar iniciar el proceso usted mismo y desviar el punto de entrada a la función que desea interceptar.

Esto significa iniciar usted mismo el proceso, interceptar su ejecución y reescribir su memoria para colocar una instrucción de salto al comienzo de la definición de una función en la memoria de una nueva función que usted controle.

Si desea interceptar las llamadas al sistema real y no puede usar ptrace, tendrá que encontrar el sitio de ejecución para cada llamada al sistema y volver a escribirlo, o puede necesitar sobrescribir la tabla de llamadas del sistema en la memoria y filtrando todo, excepto el proceso que desea controlar.

Answer 3

Ningún método que pueda soñar en el espacio de usuario funcionará sin problemas con cualquier aplicación. Afortunadamente para ti, ya hay soporte para hacer exactamente lo que quieres hacer en el kernel. Las Kprofes y Kretprobes le permiten examinar el estado de la máquina que acaba de preceder y después de una llamada al sistema.

Documentación aquí: https://www.kernel.org/doc/Documentation/kprobes.txt

Answer 4

Si el código está desarrollando es relacionada con el proceso, a veces se puede desarrollar implementaciones alternativas sin romper el código existente. Esto es útil si está reescribiendo una llamada al sistema importante y desea un sistema completamente funcional con el que depurarlo.

Para su caso, está reescribiendo el algoritmo mmap() para aprovechar una nueva y emocionante función (o mejorarla con una nueva característica). A menos que obtenga todo correctamente en el primer intento, no sería fácil depurar el sistema: una llamada al sistema mmap() que no funciona seguramente producirá un sistema que no funciona. Como siempre, hay esperanza.

A menudo, es seguro mantener el algoritmo restante en su lugar y construir su reemplazo en el lateral.Esto se puede conseguir mediante el uso de la identificación de usuario (UID) como un condicional con la cual decidir qué algoritmo de empleo:

if (current->uid != 7777) { 
/* old algorithm .. */ 
} else { 
/* new algorithm .. */ 
} 

Todos los usuarios excepto UID 7777 utilizarán el algoritmo antiguo. Puede crear un usuario especial, con UID 7777, para probar el nuevo algoritmo. Esto hace que sea mucho más fácil probar el código crítico relacionado con el proceso.