【发布时间】：2015-11-16 16:09:19
【问题描述】：
我想从 kext 中的 PID 检索进程的路径，如下所示：Get name from PID? 但是，sys/proc_info.h 和 libproc.h 不再可用（afaik）。
有没有其他方法可以从 kext 中为进程 struct proc *p 检索 proc_info？
【问题讨论】：
标签： macos kernel-extension xnu
【发布时间】：2015-11-16 16:09:19
【问题描述】：
应该返回进程的主要可执行文件vnode、proc_getexecutablevnode() 的函数位于私有 KPI 中，该 KPI 仅适用于 Apple 发布的 kexts。
它所依赖的信息应该存储在 struct proc 的 p_textvp 字段中，这又不是公共 ABI 的一部分 - Apple 可以选择更改其布局，因此即使您将其定义导入您的代码，您的代码在未来或旧版 OS X 中可能不正确。但是，it turns out this field is NULL anyway。
您也许能够通过 sysctl 机制获取信息，但我看不到明显的方法。您应该能够通过proc_info() 系统调用获取用户空间中的信息。 Apple 没有记录它，但您可以阅读源代码。这是由存储在进程地址空间中的信息支持的，因此，进程实际上可以伪造它。
最后，如果您的 kext 在引导时加载，您可以通过在 KAUTH_SCOPE_FILEOP 中注册一个 KAUTH 侦听器自己跟踪进程的可执行文件。每当进程（成功）调用 exec() 函数之一时，事件 KAUTH_FILEOP_EXEC 会告诉您，包括有问题的 vnode。在 OS X/macOS 上，posix_spawn() 更为常见，因为 fork/exec 被明确禁止用于多线程进程，并且 macOS 上的大多数进程都有多个线程。这在这里是相关的，因为由posix_spawn() 触发的KAUTH_FILEOP_EXEC 事件处理程序实际上在父 进程的上下文中运行。所以你需要做一些额外的争论来将可执行的 vnode 信息与子进程 PID 关联起来。
还有一点需要注意：请注意，可执行文件的路径 不一定是明确定义的。与 Windows 不同，正在执行的文件可以移动或删除，因此路径可以更改或完全消失。此外，文件可以被硬链接，在这种情况下它们有多个路径。 vnode_t 是识别文件的内核类型，无论其名称/路径/等如何。 - 常规用户进程将始终具有可执行文件vnode，但vnode 可能没有有效路径。确保您的代码不会出现这种情况。
【讨论】：
-
非常感谢@pmdj。我会尝试
p_textvp方法。让你知道它成功了！ -
"p_textvp 没有被使用。在 Darwin 中，proc 不是地址空间的根；任务是。对于任务的地址空间，没有“vnode”的概念，因为它最初不一定是通过映射来填充的。[...]" cont
-
你知道如何访问
p->p_textvp吗？由于我收到incomplete definition of type 'struct proc错误，例如here。添加proc_internal.h会导致很多其他关于lck_mtx_t结构定义不可见的错误。 -
您链接的邮件列表帖子中的建议是合理的 - 您通常不想查看私有结构 - 您的 kext 可能会导致 OSX 版本（而不是标头版本）中的内核恐慌。此外，听起来
p_textvp无论如何都是NULL（我不知道这一点），所以无论如何都没有意义。您需要可执行 vnode 做什么，为什么我在答案末尾建议的解决方案对您不起作用？ -
好的，谢谢，后者似乎更努力，但我会尝试那个。