7
votes

I'm interested in developing some kind of ring0 kernel-mode debugger for x86-64 in Common Lisp that would be loaded as a Linux kernel module and as I prefer Common Lisp to C in general programming, I wonder how different Common Lisp implementations would fit this kind of programming task.

The debugger would use some external disassembling library, such as udis86 via some FFI. It seems to me that it's easiest to write kernel modules in C as they need to contain C functions int init_module(void) and void cleanup_module(void) (The Linux Kernel Module Programming Guide), so the kernel-land module code would call Common Lisp code from C by using CFFI. The idea would be to create a ring0 debugger for 64-bit Linux inspired by the idea of Rasta Ring 0 Debugger, that is only available for 32-bit Linux and requires PS/2 keyboard. I think the most challenging part would be the actual debugger code with hardware and software breakpoints and low-level video, keyboard or USB input device handling. Inline assembly would help a lot in that, it seems to me that in SBCL inline assembly can be implemented by using VOPs (SBCL Internals: VOP) (SBCL Internals: Adding VOPs), and this IRC log mentions that ACL (Allegro Common Lisp), CCL (Clozure Common Lisp) and CormanCL have LAPs (Lisp Assembly Programs). Both ACL and CormanCL are proprietary and thus discarded, but CCL (Clozure Common Lisp) could be one option. Capacity of building standalone executables is a requirement too; SBCL which I'm currently using has it, but as they are entire Lisp images, their size is quite big.

My question is: is it viable to create a ring0 kernel-mode debugger for Intel x86-64 in Common Lisp, with low-level code implemented in C and/or assembly, and if it is, which Common Lisp implementations for 64-bit Linux best suit for this kind of endeavour, and what are the pros and cons if there are more than one suitable Common Lisp implementation? Scheme can be one possible option too, if it offers some benefits over Common Lisp. I am well aware that the great majority of kernel modules are written in C, and I know C and x86 assembly well enough to be able to write the required low-level code in C and/or assembly. This is not an attempt to port Linux kernel into Lisp (see: https://stackguides.com/questions/1848029/why-not-port-linux-kernel-to-common-lisp), but a plan to write in Common Lisp a Linux kernel module that would be used as a ring0 debugger.

2
You could probably run the lisp part in a user process and just communicate with it from the debugger. Should be much easier to achieve.Alexey Frunze
@AlexeyFrunze That might be a good idea, probably makes things a lot easier.nrz
One downvote, one upvote. I'd like to know why a downvote?nrz
It's basically off-topic and can't be answered. Please read the FAQ. If you want to discuss project ideas and questions whether technology is usable, you might want to go to discussion forums. Stackoverflow is a Q&A site for real problems, not for discussing general questions like "can I write a graphics driver in Lisp, Scheme or whatever". If you have a question like 'I'm writing a graphics driver in Lisp and in this routine I get random errors, how can I fix it?' - then this might be useful here. Still, if areas are too narrow, you better ask on specialized lists.Rainer Joswig
this is very interesting. Why not post to reddit's r/lisp, as that will be more congenial to these questions?Paul Nathan

2 Answers

2
votes

Nope, it would not be feasible to implement a kernel module in CL for the obvious reason that just to make that work you will need to do lot of hacks and may end up loosing all the benefit the lisp language provide and your lisp code will look like C code in S-expressions.

Write your kernel module to export whatever functionality/data you need from kernel and then using ioctl or read/write operations any user mode program can communicate with the module.

I am not sure if there is any kernel module which is generic enough that it implement Lisp (or may be its subset) such that you write code in Lisp and this generic module reads the lisp code and run it as sub component, basically Kernel -> Generic lisp module -> your lisp code (that will run in kernel).

3
votes

You might want to take a look at the Feb 2 2008 lispvan talk "Doing Evil Things with Common Lisp" by Brad Beveridge on working with a filesystem driver from SBCL.

Talk description & files

In it he mentions:

"A C/C++ Debugger written in CL??

Totally pie in the sky right now

But, how cool would that be?

Not that much of a stretch, only need to be able to write to memory where the library is located to insert break points & then trap signals on the Lisp side

Could use dirty tricks to replace the C functions with calls to Lisp functions

Apart from some details, it's probably not that hard – certainly nothing “new”

The dirty trick would involve overwriting the C code with another jump (branch without link) into a Lisp callback. When the Lisp code returns it can jump directly back to the original calling function via the link register.

Also, I'm totally glossing over the real difficulty in writing a debugger – it would be time consuming."