上下文如下：
此外，在支持 32 位系统调用表的系统（例如 i686 和 x86_64）中需要遵循以下规则。
我试图弄清楚这意味着什么，以及如何检查我的系统是否需要此规则。他们引用了chown和chown32命令/（可能是系统调用），并继续围绕它讨论系统架构。我只关心Linux，但我不仅仅关心x86。
在 的输出中lscpu，您的字段如下CPU op-mode所示：
CPU op-mode(s): 32-bit, 64-bit
适用于x86_64支持双架构的处理器。我认为只有在无法解释对方指令的系统上才会显示 32 或 64。
我的困境是在没有它的遗留系统上以编程方式解决这个问题（我最终将其编写为Python）lscpu。我已经检查过这个问题他们谈论寻找 64 位兼容性，但我正在努力在相反的用例中使用这些。
总结一下到目前为止为什么这是一个问题：
lscpu不是机器- 我跑去
sudo find / -iregex .*lscpu.*确认
- 我跑去
/proc/cpuinfo通过以结尾的标志解释 64 位兼容性_lm（据我所知，不是 32 位兼容性）uname是不够的：它显示了主要体系结构，虽然可以安全地假设x86_64无疑也支持 32 位，但将已知体系结构映射到兼容性似乎并不是解决此特定问题的最可靠或最有效的方法hwinfo不在机器上getconf LONG_BIT检查 64 位兼容性lshw不在机器上
我可能忽略了一些东西，同样也可能我作为一名程序员对这个主题了解不够。有人可以帮助我了解如何以编程方式（即获取精确或可解析输出的某种方法）检查我的系统是否具有 32 位兼容性吗？
答案1
我认为你正在关注RHEL 5 安全技术实施指南。
“我的 Linux 系统支持 32 位系统调用表吗？”这是一个非常有趣的问题，正如吉尔斯提到的，该网站还没有最终解决这个问题。这也是一个很难回答的问题。
我首先将其简化为 STIG 上下文，IE“我的 Linux 系统是否支持 i386 系统调用表？”（我们稍后会重新讨论这个更普遍的问题。）您无法从正在运行的内核获取受支持的系统调用的明确列表，但在这种情况下我们不需要：我们需要做的就是寻找系统调用入口点。 i386 入口点的命名很方便：本机 32 位调用和 64 至 32 位模拟层使用的外部可见函数是do_fast_syscall_32和do_int80_syscall_32。检查这些内容的最佳方法是在其中查找它们/proc/kallsyms（我希望没有另一个 STIG 规则禁止这样做......）。如果它们存在，则当前核心支持i386系统调用，需要lchown32审计规则。
阅读此处有关此类主题的其他答案，您会发现在正在运行的系统上测试系统调用支持的典型方法是尝试调用系统调用。审核可能不合适的系统时，因为它应该触发审核规则。它还可能在审核时导致误报，因为它通常依赖于支持相关系统调用的内核以及提供必要框架的系统。
使用 和其他类似工具的结果lscpu也会产生误导，因为它们报告了已安装的中央处理器能力，而不是系统的能力。例如， CPU 标志中的lscpu硬编码等效项：lm、zarch或sun4[uv]告诉它可以使用 32 位和 64 位支持，这是从 CPU 的角度来看的，但lscpu无法确定系统的其余部分是否也支持它（也不应该）。
重新审视更普遍的问题“我的 Linux 系统支持 32 位系统调用表吗？”，确定答案始终取决于体系结构。如果我们尝试查看系统调用来确定答案，则需要考虑架构上的系统调用历史记录；例如，chown3232 位体系结构不一定支持同级。同样，寻找入口点也是依赖于架构的。
因此，我认为你的问题没有一个普遍的答案；答案必须至少考虑目标架构。