Libseccomp: BUG：seccomp_arch_add() 在字节序不匹配时返回 -EEXISTS

创建于 2017-06-20  ·  18评论  ·  资料来源: seccomp/libseccomp

（请注意，我的问题描述以 golang 开头，但实际上是 C 问题，见下文）

我今天正在编写一些单元测试，在我的 amd64 系统上练习 ScmpFilter.AddArch(seccomp.ArchPPC)。 这没有返回任何错误，但是架构没有添加到过滤器中（如通过 exportPFC 可见）。

这是一个简单的复制器（需要在 amd64 或 i386 上运行）：

package main

import (
    "os"
    "github.com/seccomp/libseccomp-golang"
)

func main() {
    secFilter, err := seccomp.NewFilter(seccomp.ActKill)
    if err != nil {
        panic(err)
    }
    err = secFilter.AddArch(seccomp.ArchPPC)
    if err != nil {
        panic(err)
    }
    secFilter.ExportPFC(os.Stdout)
}

经过一些调试后发现，如果字节序不匹配，seccomp_arch_add() 将返回 EEXIST。 在 db.c:db_col_db_add() 中有：

if (col->endian != 0 && col->endian != db->arch->endian)
        return -EFAULT;

golang 代码（理所当然地）忽略了导致我观察到的行为的 EEXIST。

我想知道 seccomp_arch_add() 会返回不同的错误代码是否有意义，也许是 EINVAL 或其他什么？ 如果这太危险（因为它可能会破坏现有的应用程序），也许可以更好地记录它。 我很高兴提供 PR。

bug prioritmedium
资料来源
picture mvo5

所有18条评论

谢谢你报告这个，我得仔细看看。

pcmoore picture pcmoore 于 2017-06-21

很抱歉我花了这么长时间才回到这个@mvo5 ，感谢您的耐心等待。

为了澄清一下，相关的当前 db.c:db_col_db_add() 如下所示：

        if (col->endian != 0 && col->endian != db->arch->endian)
                return -EEXIST;

...我认为原始问题报告中的上述版本是本地修补副本以解决该问题。 也就是说，在这里更改返回的错误听起来很合理； 我们至少在其他一些 arch/endian 代码中一直使用 EDOM，这对您来说听起来合理吗？

你怎么看@mheon？

看起来我们可能还应该更新 db.c:db_col_merge() 。

pcmoore picture pcmoore 于 2019-01-15
👍1

从 API 的角度来看，我绝对认为进行更改是很有意义的 - 重载错误代码对于调试来说总是有问题的。

在 libseccomp-golang 方面，只要保持负面的 ERRNO 约定，就不需要任何代码更改； 也许在 AddArch 上的几行注释来解释新错误的含义，这样 API 文档就完整了。

mheon picture mheon 于 2019-01-15

Travis 仍然运行太旧的内核，因此测试 #47 再次失败。 正如@pcmoore 不久前提到的，我将尝试在测试中添加一些

否则，此更改的其他所有内容在我的书中看起来都不错

drakenclimber picture drakenclimber 于 2019-02-04

@drakenclimber我想你的意思是测试 46，而不是 47，对吧？

几个月前，我为实时测试添加了 API 级别检查，但我认为bpf-sim 测试不需要它，对吗？ 在BPF-SIM测试运行干净...？

pcmoore picture pcmoore 于 2019-02-04

对于上述运行，Travis 肯定在测试 #47 (KILL_PROCESS) 上呕吐。 今天早上，当我将 master 的 HEAD 推送到一个单独的分支作为健全性检查时，我也看到了同样的失败。

测试 47-live-kill_process%%001-00001 结果：FAILURE 47-live-kill_process 3 KILL_PROCESS rc=12

我们很久以前就讨论过这个，所以我的记忆可能有点模糊，但我认为 Travis 在 KILL_PROCESS 测试中存在问题，因为引入该功能时 Travis 的内核比 4.14 旧。

还是我疯了……完全记错了？

drakenclimber picture drakenclimber 于 2019-02-05

嗯，我们看的是同一个日志吗？ 我正在查看下面的构建和日志：

...显示以下结果（此处仅复制了“c”测试，“python”结果相同）：

 batch name: 46-sim-kill_process
 test mode:  c
 test type:  bpf-sim
Test 46-sim-kill_process%%001-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%002-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%003-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%004-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%005-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%006-00001 result:   ERROR 46-sim-kill_process rc=12
 batch name: 47-live-kill_process
 test mode:  c
 test type:  live
Test 47-live-kill_process%%001-00001 result:   SKIPPED (must specify live tests)

...是的，旧内核在某些实时测试中确实存在问题，但这应该已在 9d4f7f69714d5af80309aa1b8a6d2c8300bb6730 中修复。

FWIW，主分支上的最后一个 Travis 构建运行干净：

我刚刚使用 master 分支触发了一个新构建，只是为了验证 Travis 是否一切正常：

pcmoore picture pcmoore 于 2019-02-05

我承认我现在_真的_很困惑。 您的链接肯定显示测试 #46 是问题所在。 但是当我点击右上角的“原始日志”链接时，它告诉我 #47 失败了。 对于上面列出的链接，原始日志将我重定向到以下位置：

drakenclimber picture drakenclimber 于 2019-02-05

所以仔细观察，我认为我们都是对的。

正如您所指出的，46 正在返回ERROR 。 #47 返回FAILURE （这是我最初搜索的内容。）

这在摘要中也可见：

Regression Test Summary
 tests run: 14090
 tests skipped: 114
 tests passed: 14090
 tests failed: 0
 tests errored: 12

Regression Test Summary
 tests run: 16
 tests skipped: 0
 tests passed: 14
 tests failed: 2
 tests errored: 0
drakenclimber picture drakenclimber 于 2019-02-05

如果我启动到 3.x 内核，我能够在我的一个系统上重现 TravisCI 的问题。 测试 46 最终在sys_chk_seccomp_action() 中遇到问题。 这最终会导致 seccomp_init() 将 NULL 上下文返回给测试。

我想测试 47 的问题是相似的，但我没有调查它的失败路径。 （虽然@pcmoore为验证 API 而添加的更改应该可以防止这种情况发生。嗯...）

我很好奇 Travis 发生了什么变化导致了这种情况。 他们是否回退到一个非常旧的内核？ 我们这边有事吗？

看起来我们需要在 bpf-sim 测试中添加一些智能来处理这个问题。 我们是要模仿添加到 *.tests 文件的 API 列还是完全做其他事情？

drakenclimber picture drakenclimber 于 2019-02-05

是的，我真的很困惑为什么它可以正常工作，而现在却没有。 Ubuntu 14.xx 这些天真的很老了，我要看看 Travis 上是否有更新的版本。

pcmoore picture pcmoore 于 2019-02-05

看起来 Ubuntu 16.04 (Xenial) 是可用的，让我们试试...

pcmoore picture pcmoore 于 2019-02-05

Commit 06f63ba691cb9df119c6759e8f0a150a2a9cbe69 让我们升级到 Ubuntu 16.04。 我是在 master 分支做这个，而不是作为 PR，因为我想强制这个切换； 如果构建中断，我们将修复它。

pcmoore picture pcmoore 于 2019-02-05
👍1

该构建似乎解决了测试问题，但 clang 刚刚在错误处理代码路径中发现了内存泄漏。 我会在一分钟内解决这个问题。

pcmoore picture pcmoore 于 2019-02-05

惊人的！ 感谢您的帮助，@pcmoore

drakenclimber picture drakenclimber 于 2019-02-05

好的，通过提交 f8854f990004e71ccb9955c33d88d82cdb97ea42，我们应该有一个干净的主分支。 它在我的个人分支上运行良好，现在正在等待主构建。

pcmoore picture pcmoore 于 2019-02-05

@drakenclimber我看到你在上面的问题日志中已经准备好了一个补丁，但我还没有看到 PR - 你还在追查补丁的一些问题还是准备好 PR 了？

pcmoore picture pcmoore 于 2019-02-18

这应该通过提交 4a35b6ea6f7c836734536420c50a2745a9e24c69 解决，现在关闭它。 如果有人发现此问题，请重新打开此问题或创建一个新问题。

pcmoore picture pcmoore 于 2019-02-18
此页面是否有帮助？
0 / 5 - 0 等级

相关问题

pcmoore picture pcmoore  ·  4评论
jdstrand picture jdstrand  ·  20评论
cgwalters picture cgwalters  ·  14评论
vasanthaganeshk picture vasanthaganeshk  ·  9评论
varqox picture varqox  ·  23评论