¿Es viable escribir un depurador en modo kernel de Linux para Intel x86-64 en Common Lisp, y con qué implementación Common Lisp [s]?

Question

Estoy interesado en desarrollar algún tipo de depurador ring0 kernel-mode para x86-64 en Common Lisp que se cargaría como un módulo kernel de Linux y como prefiero Common Lisp a C en programación general, me pregunto cómo diferentes Common Lisp las implementaciones se adaptarían a este tipo de tarea de programación.

El depurador utilizaría alguna biblioteca externa de desmontaje, como udis86 a través de FFI. Me parece que es más fácil escribir módulos kernel en C ya que necesitan contener las funciones C int init_module(void) y void cleanup_module(void) (The Linux Kernel Module Programming Guide), por lo que el código del módulo kernel-land llamaría al código Common Lisp desde C usando CFFI. La idea sería crear un depurador ring0 para Linux de 64 bits inspirado en la idea de Rasta Ring 0 Debugger, que solo está disponible para Linux de 32 bits y requiere teclado PS/2. Creo que la parte más desafiante sería el código del depurador real con puntos de interrupción de hardware y software y el manejo de dispositivos de entrada de video, teclado o USB de bajo nivel. El ensamblaje en línea ayudaría mucho en eso, me parece que en SBCL el ensamblaje en línea se puede implementar usando VOP (SBCL Internals: VOP) (SBCL Internals: Adding VOPs), y este IRC log menciona que ACL (Allegro Common Lisp), CCL (Clozure Common Lisp) y CormanCL tienen LAP (Lisp Programas de ensamblaje). Tanto ACL como CormanCL son propietarios y, por lo tanto, descartados, pero CCL (Clozure Common Lisp) podría ser una opción. La capacidad de construir ejecutables independientes es un requisito también; El SBCL que estoy usando actualmente lo tiene, pero como son imágenes Lisp completas, su tamaño es bastante grande.

Mi pregunta es: es viable para crear un depurador de modo de núcleo ring0 para Intel x86-64 en Common Lisp, con código de bajo nivel implementado en C y/o montaje, y si lo es, lo cual Común Las implementaciones de Lisp para Linux de 64 bits son las mejores para este tipo de empeño, y ¿cuáles son los pros y los contras si hay más de una implementación de Common Lisp adecuada? El esquema también puede ser una opción posible, si ofrece algunos beneficios sobre Common Lisp. Soy consciente de que la gran mayoría de los módulos kernel están escritos en C, y sé que C y x86 se ensamblan lo suficientemente bien como para poder escribir el código de bajo nivel requerido en C y/o ensamblaje. Esto no es un intento de portar kernel de Linux a Lisp (ver: https://stackoverflow.com/questions/1848029/why-not-port-linux-kernel-to-common-lisp), sino un plan para escribir en Common Lisp un módulo de kernel de Linux que se usaría como un ring0 depurador.

Answer 1

No, no sería factible implementar un módulo kernel en CL por la razón obvia de que solo para hacerlo funcionar tendrá que hacer muchos hacks y puede terminar perdiendo todos los beneficios que el lenguaje lisp brinda y su el código lisp se verá como el código C en S-expressions.

Escriba su módulo kernel para exportar cualquier funcionalidad/datos que necesite del kernel y luego use las operaciones ioctl o de lectura/escritura, cualquier programa en modo usuario puede comunicarse con el módulo.

No estoy seguro de si hay algún módulo kernel que sea lo suficientemente genérico como para implementar Lisp (o puede ser su subconjunto) de forma que escriba código en Lisp y este módulo genérico lea el código lisp y lo ejecute como subcomponente , básicamente Kernel -> Generic lisp module -> tu código de lisp (que se ejecutará en kernel).

Answer 2

Es posible que desee echar un vistazo a la charla de lispvan del 2 de febrero de 2008 "Haciendo cosas malas con Common Lisp" por Brad Beveridge sobre cómo trabajar con un controlador del sistema de archivos de SBCL.

Talk description & files

En él se menciona:

"A C/C++ depurador escrito en CL ??

totalmente castillos en el aire en este momento

Pero, lo genial que sería?

No es que gran parte de un tramo, sólo tiene que ser capaz de escribir en la memoria donde se encuentra la biblioteca para insertar puntos de quiebre & entonces señales de trampa en el lado Lisp

podría usar trucos sucios para reemplazar las funciones de C con llamadas a funciones Lisp

Aparte de algunos detalles, que probablemente no es tan difícil - ciertamente nada “nuevo”

el truco sucio implicaría sobrescribir el código C con otro salto (rama sin enlace) en una devolución de llamada Lisp . Cuando el código Lisp retorna, puede saltar directamente a la función de llamada original a través del registro de enlace.

Además, estoy totalmente pasando por alto la verdadera dificultad para escribir un depurador - sería mucho tiempo "