Hallo @srd424. Ich möchte sicherstellen, dass ich verstehe, wonach Sie in dieser Ausgabe fragen ... für mich klingt es so, als würden Sie im Grunde gerne wissen, ob libseccomp über einen bestimmten Systemaufruf "weiß", unabhängig davon, ob dieser bestimmte Systemaufruf auf diesem Arch implementiert ist /ABI, ja?

Wenn ja, sollten Sie seccomp_syscall_resolve_name(...) , um die gewünschten Informationen zu erhalten. Wenn der Rückgabewert __NR_SCMP_ERROR ist, ist der Systemaufruf für libseccomp unbekannt. Wenn er positiv ist, existiert der Systemaufruf im nativen Arch/ABI, und wenn er negativ ist, existiert der Systemaufruf nicht auf dem nativen Arch/ ABI. Funktioniert das für dich?

Das könnte die Filter... langatmig machen!

Ich hatte gehofft, eine Filterregel zu haben, die die Systemaufrufnummer mit der höchsten bekannten vergleicht, und wenn sie größer ist, ENOSYS , andernfalls EPERM (vorausgesetzt, dass Systemaufrufe auf der Whitelist verarbeitet wurden nach einer früheren Regel.)

Wenn ich mir jedoch die Details für seccomp_rule_add anschaue, bin ich mir nicht sicher, ob das funktionieren wird. Die Systemrufnummer wird speziell behandelt. Vermutlich könnte dafür ein Roh-BPF-Filter konstruiert werden, aber das wird einige invasivere Änderungen an libseccomp bedeuten - wahrscheinlich über meiner Gehaltsstufe!

Es kann sinnvoll sein, libseccomp eine sinnvolle Funktionalität hinzuzufügen, da ich vermute, dass das ursprüngliche Problem bei mehreren Benutzern der Bibliothek auftreten kann. Es sieht so aus, als ob es (nur?) eine Frage der Generierung einer etwas ausgeklügelteren Standardaktion wäre.

Das könnte die Filter... langatmig machen!

Ich bin mir nicht ganz sicher, was Sie hier meinen ... ? Der Aufruf von seccomp_syscall_resolve_name(...) beeinflusst den Filter nicht wirklich, er fragt nur die interne libseccomp-Systemaufruf-Datenbank ab, um die Systemaufruf-Auflösung durchzuführen. Sie können es einmal, tausendmal oder nie aufrufen und Ihr Filter wird genau derselbe sein :)

Ich hatte gehofft, eine Filterregel zu haben, die die Systemaufrufnummer mit der höchsten bekannten vergleicht, und wenn sie größer ist, ENOSYS zurückgeben, andernfalls EPERM zurückgeben (vorausgesetzt, Systemaufrufe auf der Whitelist wurden von einer früheren Regel behandelt.)

Okay, ich glaube, ich beginne zu verstehen, wonach du jetzt fragst. Sie möchten, dass der Filter selbst, nicht der Anwendungscode, eine bestimmte Aktion ausführt (im obigen Beispiel ENOSYS zurückgibt), wenn der Systemaufruf libseccomp unbekannt ist? Ist das im Grunde so oder übersehe ich wieder etwas?

Dieser Kommentar im zweiten oben erwähnten Thread hat mich zum Schmunzeln gebracht :+1:

Ich habe versucht, eine Diskussion über das ENOSYS-Handling in libseccomp zu eröffnen unter
https://github.com/seccomp/libseccomp/issues/286 , aber wahrscheinlich nicht
sehr stimmig sein..

Nachdem ich die von dir erwähnten Threads durchgelesen habe, denke ich, dass ich auf der gleichen Seite bin.

Wenn jemand (libseccomp, nspawn, wer auch immer) ENOSYS , dann wird glibc versuchen, vom neueren Systemaufruf, zB openat2 , auf den älteren Systemaufruf, zB openat . Die Rückgabe von EPERM an glibc lässt glibc denken, dass der Aufruf nicht erlaubt war, und glibc gibt auf. Ist das eine faire Umformulierung des ursprünglichen Kommentars in dieser Ausgabe?

Ich finde die Bitte berechtigt. Ich muss noch etwas nachdenken, ob libseccomp diese Anforderungen erfüllen kann, aber ich habe an dieser Stelle keine Einwände. Hier gibt es definitiv Möglichkeiten, die Endbenutzererfahrung zu verbessern.

Danke für die RFE.

Wenn jemand (libseccomp, nspawn, wer auch immer) ENOSYS , dann wird glibc versuchen, vom neueren Systemaufruf, zB openat2 , auf den älteren Systemaufruf, zB openat . Die Rückgabe von EPERM an glibc lässt glibc denken, dass der Aufruf nicht erlaubt war, und glibc gibt auf. Ist das eine faire Umformulierung des ursprünglichen Kommentars in dieser Ausgabe?

Ja, das hört sich richtig an. Die Meinung der Systemd-Leute ist, dass EPERM die meiste Zeit für verweigerte Systemaufrufe angemessen ist, vermutlich weil es dem Endbenutzer / Admin "nicht erlaubt" übermittelt. Daher die Idee, zwischen "neuen" und "alten" Systemaufrufen zu unterscheiden und ENOSYS für alles Unerkannte durchzuführen. Ich gehe davon aus, dass wir aus Leistungsgründen nicht jeden einzelnen Systemaufruf im BPF aufzählen und testen möchten, daher schien das Verfolgen einer hohen Wassermarke für die bekannten Systemaufrufnummern pro Arch der "beste Versuch" zu sein.

Wäre interessant zu wissen, was Docker, Podman, lxc usw. mit ihrer Seccomp-Filterung machen, um zu sehen, ob sie davon profitieren würden. In der Zwischenzeit habe ich einen Patch für nspawn veröffentlicht, der das Protokollieren von seccomp-Ereignissen ermöglicht, was das Debuggen etwas einfacher machen würde.

Ich finde die Bitte berechtigt. Ich muss noch etwas nachdenken, ob libseccomp diese Anforderungen erfüllen kann, aber ich habe an dieser Stelle keine Einwände. Hier gibt es definitiv Möglichkeiten, die Endbenutzererfahrung zu verbessern.

Danke für die RFE.

Ich stimme @drakenclimber zu , diese Anfrage klingt vernünftig, ich glaube, ich brauche nur noch etwas Zeit, um über mögliche Lösungen nachzudenken :)

Auf einer ziemlich einfachen Ebene ähnelt dies RFE #11 und am Ende ist dies möglicherweise der einfachste Weg, dies auf eine Weise zu implementieren, die für Anwendungen nicht schrecklich ist: Eine Anwendung kann eine maximal unterstützte Kernel-API-Version angeben, z v5.8 (offensichtlich tokenisiert) sowie eine gegebene Aktion für alles darüber hinaus und dann erledigt libseccomp den Rest. Würde das für euch @srd424 funktionieren?

Hallo, dies wurde auch in https://github.com/systemd/systemd/pull/16739 diskutiert

eine Anwendung kann eine maximal unterstützte Kernel-API-Version angeben, zB v5.8 (offensichtlich tokenisiert), sowie eine gegebene Aktion für alles, was darüber hinausgeht, und dann erledigt libseccomp den Rest.

Das würde super funktionieren. In systemd/systemd-nspawn möchten wir benutzerdefinierte Fehler für alle explizit zugelassenen und abgelehnten Systemaufrufe zurückgeben, EPERM für alle anderen in der "unterstützten Kernel-API-Version" und ENOSYS für alle neuen.

Ich denke, die Umsetzung wäre nicht allzu kompliziert. Für amd64 können "bekannte" Systemaufrufe beispielsweise als n <= 181 || 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439 ausgedrückt werden. Und solche Ausdrücke können leicht programmatisch aus den Syscall-Tabellen generiert werden.

94 könnte auch verwandt sein.

Ich habe heute Morgen zu wenig Koffein, aber würde uns das ENOSYS-Handling dann die Möglichkeit geben, große Zulassungslisten in kleine Verweigerungslisten umzuwandeln, um einen möglichen Leistungsgewinn zu erzielen?

Ich denke, die Umsetzung wäre nicht allzu kompliziert. Für amd64 können "bekannte" Systemaufrufe beispielsweise als n <= 181 || . ausgedrückt werden 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439. Und solche Ausdrücke können leicht programmatisch aus den Syscall-Tabellen generiert werden.

Wie Sie andeuten, wird der tatsächliche BPF sowohl für Arch/ABI als auch für die Kernel-Version spezifisch sein. Im obigen x86_64-Beispiel wird der BPF nicht so schlecht sein, aber bei anderen Arches/Versionen haben wir nicht so viel Glück. Unabhängig davon sind dies jetzt zwei Probleme, die effektiv dasselbe verlangen, also denke ich, dass wir dies tun möchten ... Ich werde nur nicht anfangen, auf und ab zu hüpfen, wie einfach es sein wird. )

94 könnte auch verwandt sein.

Irgendwie ja, irgendwie nein. Es handelt sich um Bereiche, aber #94 handelt von vom Aufrufer spezifizierten Argumentbereichen (was meiner Meinung nach immer noch etwas ist, was wir tun wollen, der PR kam gerade zu einem schlechten Zeitpunkt und ich denke, die API muss etwas optimiert werden), während wir hier darüber sprechen implizit erstellte Systemaufrufbereiche, die von der Bibliothek selbst generiert werden.

Ich habe heute Morgen zu wenig Koffein, aber würde uns das ENOSYS-Handling dann die Möglichkeit geben, große Zulassungslisten in kleine Verweigerungslisten umzuwandeln, um einen möglichen Leistungsgewinn zu erzielen?

Aus Anwendungssicht, zB systemd, wenn Sie versuchen, "neue" Systemaufrufe zu blockieren, dann ja ... vorausgesetzt, wir sprechen über dasselbe :)

Um genauer zu sein .. im Moment muss jeder, der versucht, bestimmte Systemaufrufe _sicher_ effektiv zu blockieren, auf die Zulassungsliste setzen, weil Sie nicht sicher sein können, welche Systemaufrufe ein neuerer Kernel hinzufügen könnte. Wenn wir libseccomp auffordern können, unbekannte Systemaufrufe automatisch zu blockieren, bedeutet das, dass wir stattdessen sicher zu einer kleinen Denylist wechseln können?

Um genauer zu sein .. im Moment muss jeder, der versucht, bestimmte Systemaufrufe _sicher_ effektiv zu blockieren, auf die Zulassungsliste setzen, weil Sie nicht sicher sein können, welche Systemaufrufe ein neuerer Kernel hinzufügen könnte. Wenn wir libseccomp auffordern können, unbekannte Systemaufrufe automatisch zu blockieren, bedeutet das, dass wir stattdessen sicher zu einer kleinen Denylist wechseln können?

Ich hoffe aufrichtig, dass wir dorthin gelangen können, denn das wäre ein absolut großartiges Feature. Docker verwendet beispielsweise derzeit eine Zulassungsliste und ihre Standardliste umfasst jetzt ~240 Systemaufrufe (und wächst ständig).

Die Auswirkungen einer so großen Liste auf die Leistung können unerschwinglich sein. Beachten Sie, dass dies durch die Verwendung der Binärbaum-Funktion, die wir in v2.5 hinzugefügt haben, etwas abgeschwächt werden kann.

Um genauer zu sein .. im Moment muss jeder, der versucht, bestimmte Systemaufrufe _sicher_ effektiv zu blockieren, auf die Zulassungsliste setzen, weil Sie nicht sicher sein können, welche Systemaufrufe ein neuerer Kernel hinzufügen könnte. Wenn wir libseccomp auffordern können, unbekannte Systemaufrufe automatisch zu blockieren, bedeutet das, dass wir stattdessen sicher zu einer kleinen Denylist wechseln können?

Ich sehe nicht, wie das funktionieren könnte. Unbekannt für libseccomp und unbekannt für den Verweigerer-Autor bedeutet normalerweise unterschiedliche Dinge. Das bedeutet, dass das konzeptionelle Problem auch dann nicht verschwinden wird, wenn libseccomp intern ein klareres Bild der unterstützten Systemaufrufe hat.

Guter Punkt - ich denke, wir brauchen gut definierte Sets, die nach Kernel-Version markiert sind, damit das funktioniert, was ein wenig diskutiert zu werden scheint.

Ich denke, die Umsetzung wäre nicht allzu kompliziert. Für amd64 können "bekannte" Systemaufrufe beispielsweise als n <= 181 || . ausgedrückt werden 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439. Und solche Ausdrücke können leicht programmatisch aus den Syscall-Tabellen generiert werden.

Wie Sie andeuten, wird der tatsächliche BPF sowohl für Arch/ABI als auch für die Kernel-Version spezifisch sein. Im obigen x86_64-Beispiel wird der BPF nicht so schlecht sein, aber bei anderen Arches/Versionen haben wir nicht so viel Glück. Unabhängig davon sind dies jetzt zwei Probleme, die effektiv dasselbe verlangen, also denke ich, dass wir dies tun möchten ... Ich werde nur nicht anfangen, auf und ab zu hüpfen, wie einfach es sein wird. )

Die Tabellen sind ziemlich fortlaufend:

>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-x86_64').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([ 1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  5,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1, 90,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-alpha').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([ 1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  3,  1,  2,  1,  1,
        1,  1,  1,  2,  1,  1,  1,  3, 12,  3,  3,  1, 11,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        2,  1,  1,  1,  1,  1,  1,  5,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1, 39,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  3,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        2,  1,  1,  1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-arm').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 2, 1, 1, 3, 1, 1, 2, 1, 2, 3, 4,
       1, 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 2, 1, 1, 1, 2, 1, 2, 3, 1, 1,
       1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 2, 2, 1, 1, 1, 3,
       1, 1, 1, 1, 1, 1, 2, 1, 3, 1, 1, 1, 1, 1, 3, 3, 1, 1, 2, 1, 1, 1,
       1, 2, 1, 1, 2, 1, 2, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-riscv64').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([  1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   2,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,  16,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1, 130,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1])

Ich habe einen Filter von "bekannten" Systemaufrufen für systemd-nspawn in https://github.com/systemd/systemd/pull/16819 implementiert https://github.com/systemd/systemd/pull/16819/commits/158e30ffd9355a7640a7276276eb9219b6c87914 enthält einen Dump einiger von libseccomp generierter Programme. Diese Dumps sind lang, daher werde ich sie hier nicht wiederholen, aber SCMP_FLTATR_CTL_OPTIMIZE macht das Programm effizienter, aber auch länger. Die Dinge könnten durch Reichweitenvergleiche ~50-mal verkürzt werden.

Ich habe diesen Thread gerade erst gefunden, um zu sagen, dass ich in ähnliche Richtungen gedacht habe und das ist definitiv etwas, das Docker/runc auch gerne gelöst hätte. Dies mit einer maximalen Kernel-Version zu tun, ist wahrscheinlich die schönste Art, dies zu tun, da dies bedeutet, dass Profilschreiber (und Container-Laufzeiten) keine Systemaufrufe verfolgen müssen, die außerhalb der Reihenfolge hinzugefügt wurden oder was der neueste Systemaufruf zum Zeitpunkt des Schreibens war das Profil.

Basierend auf der obigen Diskussion sieht es so aus, als ob die meisten (alle?) Leute hier glauben, dass Problem Nr. 11 der richtige Weg ist, dieses Problem zu lösen; Hat jemand ein Problem damit, dieses Thema zu schließen, um zukünftige Diskussionen auf das ursprüngliche Thema (#11) zu verschieben?