如何在 PPC Linux 上运行时挂接系统调用表?

发布于 2024-09-14 19:27:18 字数 1095 浏览 15 评论 0原文

主题: PPC 汇编语言 - Linux Loadble 内核模块

详细信息: 当系统调用表钩子中的内核调用时,如何访问本地 TOC 区域(r2)?

我为 Linux 编写了一个可加载的内核模块,它使用系统调用表挂钩来拦截系统调用并在将调用传递给原始处理程序之前记录有关它们的信息。这是安全产品的一部分。我的模块运行良好,并且在生产代码中运行在各种 Linux 内核版本和发行版上,其中 32 位和 64 位内核都在 x86 硬件上运行。

我试图将此代码移植到 Linux 上的 PPC 处理器上运行,但遇到了一些问题。使用 Linux 内核源代码,很容易看出系统调用表在 PPC 上的不同实现方式。我可以用我自己编译的处理程序中的函数地址替换表中的条目,没有问题。

但是,这是我遇到的问题。 PPC ABI 使用称为目录 (TOC) 地址的东西,该地址存储在 CPU 的 R2 寄存器中,并期望通过使用该寄存器中包含的地址(TOC 地址)的偏移量来寻址模块的全局和本地数据。这在进行函数调用的正常情况下工作得很好,因为编译器知道在进行调用之前将模块的 TOC 地址加载到寄存器中(或者它已经在那里,因为通常您的函数是由您自己的代码调用的)。

但是,当我将自己的函数的地址(从运行时加载的内核模块)放入系统调用表时,内核使用 R2 值调用我的处理程序,该值不是我编译的 C 代码所期望的值,因此我的代码得到控制,但无法访问其数据。

有人知道有任何示例代码显示如何处理这种情况吗?我无法重新编译内核。这应该是运行时系统调用表挂钩的一个简单例子,但我还没有弄清楚,或者找到任何特定于 PPC 的示例。

想法包括:

手动编写一个汇编语言存根,用于保存 R2 值,使用我的本地 TOC 地址加载寄存器,执行我的代码,然后在调用原始处理程序之前恢复旧值。我没有丰富的 PPC 组装经验来完成此操作,我也不确定它是否有效。

一些神奇的 gcc 选项可以在不使用 TOC 的情况下生成我的代码。有一个已记录的 gcc 选项 "-mno-toc" 在我的 PPC6 Linux 上不起作用。看起来它可能只是系统 V.4 和嵌入式 PowerPC 的一个选项。

非常感谢任何帮助!

谢谢!

Subject: PPC Assembly Language - Linux Loadble Kernel Module

Detail: How access local TOC area (r2) when called from kernel in syscall table hook?

I have written a loadable kernel module for Linux that uses syscall table hooking to intercept system calls and log information about them before passing the call on to the original handler. This is part of a security product. My module runs well and is in production code running on a large variety of Linux kernel versions and distributions with both 32 and 64 bit kernels all running on x86 hardware.

I am trying to port this code to run on Linux for PPC processors and ran into a few problems. Using the Linux kernel source, it is easy enough to see how the system call table is implemented differently on PPC. I can replace entries in the table with function addresses from my own compiled handlers, no problem.

But, here's the issue I'm having trouble with. The PPC ABI uses this thing called a Table Of Contents (TOC) address which is stored in the CPU's R2 register and expects to address a module's global and local data by using an offset from the address (TOC address) contained in that register. This works fine in normal cases where a function call is made because the compiler knows to load the module's TOC address into the register before making the call (or its already there becasue normally your functions are called by your own code).

However, when I place the address of my own function (from my loaded kernel module at runtime) into the system call table, the kernel calls my handler with an R2 value that is not the one my compiled C code expects, so my code gets control without being able to access its data.

Does anybody know of any example code out there showing how to handle this situation? I cannot recompile the kernel. This should be a straightforward case of runtime syscall table hooking, but I have yet to figure it out, or find any examples specific to PPC.

Ideas include:

Hand coding an assembly language stub that saves the R2 value, loads the register with my local TOC address, executes my code, then restores the old value before calling the original handler. I don't have the depth of PPC assembly experience to do this, nor am I sure it would work.

Some magic gcc option that will generate my code without using TOC. There is a documented gcc option "-mno-toc" that doesn't work on my PPC6 Linux. It looks like it may only be an option for system V.4 and embedded PowerPC.

Any help is greatly appreciated !

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

债姬 2024-09-21 19:27:18

Linux 有一个通用的系统调用审计基础设施,可在 powerpc 上运行,您可以从用户空间访问。您是否考虑过使用它而不是编写内核模块?

Linux has a generic syscall audit infrastructure which works on powerpc and you can access from user space. Have you considered using that rather than writing a kernel module?

淡看悲欢离合 2024-09-21 19:27:18

您需要一个存根来加载r2。内核源码中有例子。

You need a stub to load r2. There are examples in the kernel source.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文