我想从kext中的PID中检索进程的路径，如下所示：Get name from PID?但是，sys/proc_info.h和libproc.h不再可用（afaik）。< / p>
还有其他方法可以从kext中检索proc_info进程{1}}吗？
答案 0 :(得分：3)
应该返回进程的主要可执行文件vnode，proc_getexecutablevnode()的函数位于私有KPI中，该KPI仅适用于Apple发布的kexts。
它依赖的信息据说存储在p_textvp的{{1}}字段中，再次不是公众ABI的一部分 - Apple可以选择更改其布局，所以即使你这样做将其定义导入到您的代码中，您的代码在将来或旧版本的OS X中可能不正确。但是，it turns out this field is NULL anyway。
你可能能够通过sysctl机制获取信息，但我看不到明显的方法。您应该能够通过struct proc系统调用获取用户空间中的信息。 Apple没有记录，但您可以阅读来源。这是由存储在进程地址空间中的信息支持的，因此，进程实际上可以伪造它。
最后，如果您的kext在引导时加载，您可以通过在proc_info()中注册KAUTH侦听器来自行跟踪进程的可执行文件。只要进程（成功）调用其中一个KAUTH_SCOPE_FILEOP函数（包括有问题的vnode），事件KAUTH_FILEOP_EXEC就会告诉您。在OS X / macOS上，exec()更常见，因为多线程进程明确禁止fork / exec，并且macOS上的大多数进程都有多个线程。这与此相关，因为posix_spawn()触发的KAUTH_FILEOP_EXEC事件处理程序实际上在父进程的上下文中运行。因此，您需要进行一些额外的争论，以将可执行的vnode信息与子进程PID相关联。
还有一点需要注意：请注意，可执行文件的路径不一定是明确定义的。与Windows不同，可以移动或删除正在执行的文件，因此路径可以更改或完全消失。此外，文件可以硬链接，在这种情况下，它们有多个路径。 posix_spawn()是标识文件的内核类型，无论其名称/路径/等。 - 常规用户进程始终具有可执行文件vnode_t，但vnode可能没有有效路径。确保您的代码不期望它。