8

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://stackoverflow.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.

4

2 回答 2

4

您可能想看看 Brad Beveridge 在 2008 年 2 月 2 日发表的关于使用 SBCL 的文件系统驱动程序的 lispvan 演讲“Doing Evil Things with Common Lisp”。

谈话描述和文件

他在其中提到:

“用 CL 编写的 AC/C++ 调试器??

现在完全是天上掉馅饼

但是,那该有多酷?

没有那么大的延伸,只需要能够写入库所在的内存以插入断点然后在 Lisp 端捕获信号

可以使用肮脏的技巧将 C 函数替换为对 Lisp 函数的调用

除了一些细节之外,这可能并不难——当然没有什么“新”</p>

肮脏的技巧将涉及用另一个跳转(没有链接的分支)覆盖 C 代码到 Lisp 回调中。当 Lisp 代码返回时,它可以通过链接寄存器直接跳转回原来的调用函数。

此外,我完全掩盖了编写调试器的真正困难——这将非常耗时。”

于 2012-09-19T07:54:37.983 回答
2

不,在 CL 中实现一个内核模块是不可行的,原因很明显,为了使这项工作你需要做很多黑客攻击,最终可能会失去 lisp 语言提供的所有好处,你的 lisp 代码看起来就像 S 表达式中的 C 代码一样。

编写内核模块以从内核导出所需的任何功能/数据,然后使用 ioctl 或读/写操作,任何用户模式程序都可以与模块通信。

我不确定是否有任何足够通用的内核模块可以实现 Lisp(或者可能是它的子集),这样您就可以在 Lisp 中编写代码,而这个通用模块读取 lisp 代码并将其作为子组件运行,基本上是内核 - > 通用 lisp 模块 -> 你的 lisp 代码(将在内核中运行)。

于 2012-09-19T07:20:48.153 回答