Libseccomp: बग: छद्म सिस्कल के लिए बीपीएफ उत्पन्न न करें

नीचे दिए गए बेहतर मसौदे के पक्ष में रिप्रोड्यूसर को हटाया गया

स्पष्ट होने के लिए, हमें अभी भी PFC में डिबगिंग उद्देश्यों के लिए छद्म-सिसकॉल का उत्सर्जन करना चाहिए, लेकिन हमें एक (बेकार) BPF फ़िल्टर नियम का उत्सर्जन नहीं करना चाहिए।

मेरी रिपोर्ट से मुद्दा बनाने के लिए धन्यवाद।

स्पष्ट होने के लिए, हमें अभी भी PFC में डिबगिंग उद्देश्यों के लिए छद्म-सिसकॉल का उत्सर्जन करना चाहिए, लेकिन हमें एक (बेकार) BPF फ़िल्टर नियम का उत्सर्जन नहीं करना चाहिए।

कृपया इस पर पुनर्विचार करें। मेरा मानना ​​है कि यह केवल चीजों को जटिल और अस्पष्ट करेगा यदि पीएफसी बीपीएफ को प्रतिबिंबित नहीं करेगा।

कृपया इस पर पुनर्विचार करें। मेरा मानना ​​है कि यह केवल चीजों को जटिल और अस्पष्ट करेगा यदि पीएफसी बीपीएफ को प्रतिबिंबित नहीं करेगा।

यदि पीएफसी से सिस्कल गायब है तो हमें कई फर्जी बग रिपोर्ट प्राप्त होंगी जो इस बारे में बात कर रही हैं कि पुस्तकालय कैसे (गैर-मौजूद) सिस्कोल के लिए एक फिल्टर जोड़ने में विफल हो रहा है।

जो लोग स्यूडो-सिस्कल की अवधारणा को समझते हैं, उनके लिए उन्हें पीएफसी आउटपुट से हटाना एक छोटी सी कवायद है। यह भी ध्यान देने योग्य है कि पीएफसी आउटपुट का उद्देश्य बीपीएफ आउटपुट की एक सटीक प्रतिलिपि नहीं है, यह केवल एक डिबगिंग टूल के रूप में है और जेनरेट किए गए फ़िल्टर कोड को देखने का एक आसान तरीका है।

जेनरेट किए गए फ़िल्टर कोड की कल्पना करने का आसान तरीका

लेकिन, तब यह _generated_ फ़िल्टर कोड की कल्पना नहीं करेगा क्योंकि उत्पन्न कोड में छद्म सिस्को अनुपस्थित होना चाहिए।

यदि पीएफसी से सिस्कल गायब है तो हमें कई फर्जी बग रिपोर्ट प्राप्त होंगी जो इस बारे में बात कर रही हैं कि पुस्तकालय कैसे (गैर-मौजूद) सिस्कोल के लिए एक फिल्टर जोड़ने में विफल हो रहा है।

यह समझना बहुत आसान है कि छद्म सिस्कल चेक कोड में मौजूद नहीं होना चाहिए (जैसा कि 'अनुकूलित' में है, क्योंकि '' आर्क के लिए ऐसे कोई सिस्को नहीं हैं '), तर्क अंतर (सशर्तों की उपस्थिति और अनुपस्थिति) की तुलना में कोड का विज़ुअलाइज़ेशन और वास्तविक कोड।

मैं पीएफसी को scmp_bpf_disasm का उपयोग करने के बजाय बीपीएफ को प्रतिबिंबित करने के लिए पसंद करूंगा क्योंकि पीएफसी आउटपुट को पढ़ना बहुत आसान है।

मैं आपकी चिंता @vt-alt को समझता हूं, और शायद भविष्य के रिलीज में हम पीएफसी के साथ ऐसा करते हैं, लेकिन यह मेरी राय है कि पीएफसी आउटपुट से स्यूडो-सिसकॉल को हटाना एक गलती है।

@drakenclimber क्या इस पर आपकी कोई मजबूत राय है?

x86_64 के लिए संशोधित पुनरुत्पादक:

#include <stdlib.h>
#include <errno.h>

#include <seccomp.h>

#include "util.h"

int main(int argc, char *argv[])
{
        int rc;
        struct util_options opts;
        scmp_filter_ctx ctx = NULL;

        rc = util_getopt(argc, argv, &opts);
        if (rc < 0)
                goto out;

        ctx = seccomp_init(SCMP_ACT_KILL);
        if (ctx == NULL)
                return ENOMEM;

        rc = seccomp_arch_add(ctx, SCMP_ARCH_X32);
        if (rc < 0)
                goto out;

        rc = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(access), 0);
        if (rc < 0)
                goto out;
        rc = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(arm_fadvise64_64), 0);
        if (rc < 0)
                goto out;

        rc = util_filter_output(&opts, ctx);
        if (rc)
                goto out;

out:
        seccomp_release(ctx);
        return (rc < 0 ? -rc : rc);
}

अद्यतन: TSKIP के साथ एक समस्या का समाधान किया गया

अभी तक पूरी तरह से परीक्षण नहीं किया गया है, लेकिन यह एक फिक्स हो सकता है - क्या आप सत्यापित कर सकते हैं कि यह संतुलित पेड़ अनुकूलन एल्गोरिदम @drakenclimber के लिए उचित है?

diff --git a/src/arch-arm.c b/src/arch-arm.c
index 3465111..4dd4b63 100644
--- a/src/arch-arm.c
+++ b/src/arch-arm.c
@@ -54,7 +54,7 @@ int arm_syscall_resolve_name_munge(const char *name)
        if (sys == __NR_SCMP_ERROR)
                return sys;

-       return sys + __SCMP_NR_BASE;
+       return (sys | __SCMP_NR_BASE);
 }

 /**
@@ -68,7 +68,7 @@ int arm_syscall_resolve_name_munge(const char *name)
  */
 const char *arm_syscall_resolve_num_munge(int num)
 {
-       return arm_syscall_resolve_num(num - __SCMP_NR_BASE);
+       return arm_syscall_resolve_num(num & (~__SCMP_NR_BASE));
 }

 const struct arch_def arch_def_arm = {
diff --git a/src/arch-x32.c b/src/arch-x32.c
index 7b97fb3..3890968 100644
--- a/src/arch-x32.c
+++ b/src/arch-x32.c
@@ -43,7 +43,7 @@ int x32_syscall_resolve_name_munge(const char *name)
        if (sys == __NR_SCMP_ERROR)
                return sys;

-       return sys + X32_SYSCALL_BIT;
+       return (sys | X32_SYSCALL_BIT);
 }

 /**
@@ -57,7 +57,7 @@ int x32_syscall_resolve_name_munge(const char *name)
  */
 const char *x32_syscall_resolve_num_munge(int num)
 {
-       return x32_syscall_resolve_num(num - X32_SYSCALL_BIT);
+       return x32_syscall_resolve_num(num & (~X32_SYSCALL_BIT));
 }

 const struct arch_def arch_def_x32 = {
diff --git a/src/gen_bpf.c b/src/gen_bpf.c
index 55a7958..ae9c3f4 100644
--- a/src/gen_bpf.c
+++ b/src/gen_bpf.c
@@ -1555,6 +1555,10 @@ static int _gen_bpf_syscalls(struct bpf_state *state,
        for (s_iter = s_tail; s_iter != NULL; s_iter = s_iter->pri_prv) {
                if (!s_iter->valid)
                        continue;
+               /* skip pseudo-syscalls */
+               if ((s_iter->num & 0x80000000) &&
+                   (state->attr->api_tskip == 0 || s_iter->num != -1))
+                       continue;

                if (*bintree_levels > 0 &&
                    ((syscall_cnt + empty_cnt) % SYSCALLS_PER_NODE) == 0)

मैं आपकी चिंता @vt-alt को समझता हूं, और शायद भविष्य के रिलीज में हम पीएफसी के साथ ऐसा करते हैं, लेकिन यह मेरी राय है कि पीएफसी आउटपुट से स्यूडो-सिसकॉल को हटाना एक गलती है।

@drakenclimber क्या इस पर आपकी कोई मजबूत राय है?

वास्तव में नहीं, लेकिन मुझे लगता है कि समस्या की जड़ यह है कि पीएफसी आउटपुट का उपयोग कई, अलग-अलग तरीकों से किया जा रहा है:

1. जैसा कि ऊपर उल्लेख किया गया है, यह नए (एर) उपयोगकर्ताओं के लिए अपने फ़िल्टर को मोटे तौर पर सत्यापित करने का एक आसान तरीका है
2. अधिक उन्नत उपयोगकर्ता उम्मीद कर रहे हैं कि यह वास्तविक BPF फ़िल्टर का एक निकट सन्निकटन होगा

शायद हम पीएफसी तर्क में --no-pseudo-syscalls ध्वज जोड़ सकते हैं? फिर यह शुरुआती उपयोगकर्ताओं के लिए समान रह सकता है, लेकिन उन्नत उपयोगकर्ता बीपीएफ का बेहतर अनुमान प्राप्त कर सकते हैं।

_अपडेट किया गया: TSKIP_ के साथ एक समस्या का समाधान किया गया

अभी तक पूरी तरह से परीक्षण नहीं किया गया है, लेकिन यह एक फिक्स हो सकता है - क्या आप सत्यापित कर सकते हैं कि यह संतुलित पेड़ अनुकूलन एल्गोरिदम @drakenclimber के लिए उचित है?

काम चल जायेगा। मैं देखना चाहता हूं कि क्या मैं एक स्वचालित परीक्षण कर सकता हूं जो इस परिदृश्य को पुन: उत्पन्न करेगा।

_अपडेट किया गया: TSKIP_ के साथ एक समस्या का समाधान किया गया
अभी तक पूरी तरह से परीक्षण नहीं किया गया है, लेकिन यह एक फिक्स हो सकता है - क्या आप सत्यापित कर सकते हैं कि यह संतुलित पेड़ अनुकूलन एल्गोरिदम @drakenclimber के लिए उचित है?

काम चल जायेगा। मैं देखना चाहता हूं कि क्या मैं एक स्वचालित परीक्षण कर सकता हूं जो इस परिदृश्य को पुन: उत्पन्न करेगा।

और निश्चित रूप से मैं आपके ऊपर दिए गए पुनरुत्पादक परीक्षण से शुरू करूंगा। धन्यवाद!

_अपडेट किया गया: TSKIP_ के साथ एक समस्या का समाधान किया गया

अभी तक पूरी तरह से परीक्षण नहीं किया गया है, लेकिन यह एक फिक्स हो सकता है - क्या आप सत्यापित कर सकते हैं कि यह संतुलित पेड़ अनुकूलन एल्गोरिदम @drakenclimber के लिए उचित है?

बाइनरी ट्री पूर्व-गणना करता है जब संचायक को संशोधित करने की आवश्यकता होती है, और इस तरह यह jge तर्क सम्मिलित करना जानता है। फ़िल्टर का निर्माण करते समय सिस्कल्स (ऊपर दिए गए प्रस्ताव की तरह) को बाहर निकालना इस तर्क को तोड़ता है।

मैंने अभी तक अपने परिवर्तनों का पूरी तरह से परीक्षण नहीं किया है :), लेकिन मुझे पूरा यकीन है कि हमें बाइनरी ट्री को छद्म-सिस्कल को हटाने के साथ काम करने के लिए कुछ इस तरह की आवश्यकता होगी। मैंने इसका उपयोग करके एक बीपीएफ बाइनरी पेड़ उत्पन्न किया और यह उचित दिखता है। जैसे-जैसे हम उत्पादन के लिए तैयार समाधान के करीब पहुंचेंगे, मैं इसे पूरी तरह से सत्यापित कर दूंगा।

@@ -1532,11 +1532,31 @@ static int _gen_bpf_syscalls(struct bpf_state *state,
                _sys_sort(db_secondary->syscalls, &s_head, &s_tail, optimize);

        if (optimize == 2) {
+               /* since pseudo-syscalls are removed from the filter, we need
+                * to calculate the syscall count by hand
+                */
+               for (s_iter = s_tail; s_iter != NULL; s_iter = s_iter->pri_prv) {
+                       if (!s_iter->valid)
+                               continue;
+
+                       /* skip pseudo-syscalls */
+                       if ((s_iter->num & 0x80000000) &&
+                           (state->attr->api_tskip == 0 || s_iter->num != -1))
+                               continue;
+
+                       syscall_cnt++;
+               }
+
                rc = _gen_bpf_init_bintree(&bintree_hashes, &bintree_syscalls,
-                                          bintree_levels, db->syscall_cnt,
+                                          bintree_levels, syscall_cnt,
                                           &empty_cnt);
                if (rc < 0)
                        goto out;
+
+               /* reset the syscall_cnt variable because later in this
+                * function it's used as a counter
+                */
+               syscall_cnt = 0;
        }

यदि हमारे पास db संरचना में "वैध" सिस्कल गणना को ट्रैक करने वाला एक चर है, तो इसे स्मार्ट/तेज बनाया जा सकता है।

शायद हम PFC तर्क में --no-pseudo-syscalls ध्वज जोड़ सकते हैं?

यह झंडा कहां जाएगा? मुझे नहीं लगता कि हम इसे बिल्ड टाइम विकल्प के रूप में चाहते हैं। मुझे लगता है कि हम एक फिल्टर विकल्प जोड़ सकते हैं, लेकिन मैं वास्तव में इसके बारे में उत्साहित नहीं हूं। मैं पीएफसी में स्यूडो-सिस्कल के साथ चिपके रहने के लिए वोट करूंगा लेकिन इसे अभी के लिए बीपीएफ (जाहिर है) से हटा दूंगा, और अगर हमें भविष्य में इसे किसी बिंदु पर बढ़ाने की आवश्यकता है तो हम कर सकते हैं।

मैंने अभी तक अपने परिवर्तनों का पूरी तरह से परीक्षण नहीं किया है :), लेकिन मुझे पूरा यकीन है कि हमें बाइनरी ट्री को छद्म-सिस्कल को हटाने के साथ काम करने के लिए कुछ इस तरह की आवश्यकता होगी। मैंने इसका उपयोग करके एक बीपीएफ बाइनरी पेड़ उत्पन्न किया और यह उचित दिखता है। जैसे-जैसे हम उत्पादन के लिए तैयार समाधान के करीब पहुंचेंगे, मैं इसे पूरी तरह से सत्यापित कर दूंगा।

मुझे संदेह था कि यह वृक्ष अनुकूलन को तोड़ने वाला था।

@drakenclimber इस पर विचार करते हुए मानक अनुकूलन की तुलना में पेड़ को बहुत अधिक प्रभावित करता है, क्या आप इस मुद्दे को लेना चाहते हैं? मेरे द्वारा कॉपी और पेस्ट किए गए कोड को जितना हो सके उतना कम या ज्यादा चोरी करने के लिए स्वतंत्र महसूस करें।

एक बात जो मुझे लगता है कि हमें "arch-arm.c" और "arch-x32.c" में परिवर्तन की परवाह किए बिना करना चाहिए क्योंकि यह अधिक समझ में आता है।

शायद हम PFC तर्क में --no-pseudo-syscalls ध्वज जोड़ सकते हैं?

यह झंडा कहां जाएगा? मुझे नहीं लगता कि हम इसे बिल्ड टाइम विकल्प के रूप में चाहते हैं। मुझे लगता है कि हम एक फिल्टर विकल्प जोड़ सकते हैं, लेकिन मैं वास्तव में इसके बारे में उत्साहित नहीं हूं। मैं पीएफसी में स्यूडो-सिस्कल के साथ चिपके रहने के लिए वोट करूंगा लेकिन इसे अभी के लिए बीपीएफ (जाहिर है) से हटा दूंगा, और अगर हमें भविष्य में इसे किसी बिंदु पर बढ़ाने की आवश्यकता है तो हम कर सकते हैं।

मैं मानता हूं कि मैंने सोचने से पहले टाइप किया था। ;)

हाँ, यह एक फ़िल्टर विकल्प होना चाहिए और यह गलत लगता है। मैं सहमत हूं; जैसा आपने ऊपर बताया है, वैसा ही करते हैं। यदि हमें प्रश्न मिलते रहते हैं, तो हम फिर से जा सकते हैं।

मैंने अभी तक अपने परिवर्तनों का पूरी तरह से परीक्षण नहीं किया है :), लेकिन मुझे पूरा यकीन है कि हमें बाइनरी ट्री को छद्म-सिस्कल को हटाने के साथ काम करने के लिए कुछ इस तरह की आवश्यकता होगी। मैंने इसका उपयोग करके एक बीपीएफ बाइनरी पेड़ उत्पन्न किया और यह उचित दिखता है। जैसे-जैसे हम उत्पादन के लिए तैयार समाधान के करीब पहुंचेंगे, मैं इसे पूरी तरह से सत्यापित कर दूंगा।

मुझे संदेह था कि यह वृक्ष अनुकूलन को तोड़ने वाला था।

@drakenclimber इस पर विचार करते हुए मानक अनुकूलन की तुलना में पेड़ को बहुत अधिक प्रभावित करता है, क्या आप इस मुद्दे को लेना चाहते हैं? मेरे द्वारा कॉपी और पेस्ट किए गए कोड को जितना हो सके उतना कम या ज्यादा चोरी करने के लिए स्वतंत्र महसूस करें।

एक बात जो मुझे लगता है कि हमें "arch-arm.c" और "arch-x32.c" में परिवर्तन की परवाह किए बिना करना चाहिए क्योंकि यह अधिक समझ में आता है।

ज़रूर। मैं इसका मालिक हो सकता हूं।

@drakenclimber "> जैसा कि ऊपर उल्लेख किया गया है, यह नए (एर) उपयोगकर्ताओं के लिए अपने फ़िल्टर को मोटे तौर पर सत्यापित करने का एक आसान तरीका है"

"छद्म सिस्कल" कर्नेल में मौजूद नहीं है और यह एक प्रसिद्ध अवधारणा भी नहीं है। यह विशुद्ध रूप से libseccomp का आविष्कार है और इसकी व्याख्या यहाँ नहीं की गई है। केवल कहा गया है कि वे ऋणात्मक संख्याएँ हैं और वे तब प्रकट होते हैं जब दिए गए syscall आर्किटेक्चर के लिए मौजूद नहीं होते हैं। यह गैर-मौजूद सिस्कल से कैसे भिन्न है? वे किस उद्देश्य से नकारात्मक हैं? नए उपयोगकर्ताओं के लिए छद्म सिस्कल अवधारणा वास्तव में भ्रमित करने वाली है।

मुझे विश्वास नहीं हो रहा है कि नए (एर) उपयोगकर्ता अपने फ़िल्टर में मौजूद गैर-मौजूद सिस्को को देखना चाहते हैं।

मुझे एक बिंदु और जोड़ने दो। यह सब सुरक्षा के क्षेत्र में है, जहां केवल सावधान और विस्तृत समझ काम करती है। आप नई अस्पष्ट अवधारणाएं (छद्म सिस्कोल की) और अभ्यावेदन (बीपीएफ और पीएफसी) के बीच अंतर बना रहे हैं। क्या यह वास्तव में नए उपयोगकर्ताओं के लिए, उन्हें और अधिक भ्रमित करने के लिए है?

@vt-alt आपकी चिंता व्यक्त करने के लिए धन्यवाद, लेकिन v2.5.0 रिलीज के लिए हम BPF फ़िल्टर से छद्म-सिस्कल को दबाने जा रहे हैं, और उन्हें PFC फ़िल्टर में प्रदर्शित करना जारी रखेंगे। मैं मानता हूं कि आप इस निर्णय से असहमत हो सकते हैं लेकिन मैं आपसे इस निर्णय का सम्मान करने के लिए कहता हूं। भविष्य के रिलीज में हम छद्म-सिस्कल (यह कई एबीआई समर्थन के लिए है) के पीछे के उद्देश्य को समझाते हुए और इसे मैनपेज में दस्तावेज करने के लिए बेहतर काम करेंगे; मैंने उसके लिए एक मुद्दा बनाया है (नीचे लिंक), उस चर्चा और किसी भी पीआर में भाग लेने के लिए आपका स्वागत है और प्रोत्साहित किया जाता है। यह भी संभव है कि हम भविष्य में पीएफसी फिल्टर के लिए अपने दृष्टिकोण को संशोधित करें, लेकिन मैं यहां कुछ भी वादा नहीं करना चाहता।

• https://github.com/seccomp/libseccomp/issues/258

एक बार फिर, हमारे ध्यान में बीपीएफ समस्या लाने के लिए धन्यवाद; आपने अगली libseccomp रिलीज़ को बेहतर बनाने में मदद की है!

#264 के माध्यम से बंद।