Libseccomp: बग: aarch64 पर 53/55 विफलताओं/त्रुटियों का परीक्षण करें

@drakenclimber मुझे यकीन नहीं है कि क्या आपके पास aarch64 सिस्टम तक पहुंच है (हो सकता है कि रास्पबेरी पाई 64-बिट बिल्ड चला रहा हो?), लेकिन मैं स्पष्ट कारणों से आपको यह असाइन करने जा रहा हूं। अगर आपके पास aarch64 सिस्टम तक पहुंच नहीं है तो मुझे बताएं और मैं इसे देख लूंगा।

संपादित करें: क्षमा करें, वह त्रुटि कोड है 14 त्रुटि नहीं 16 (नीचे सुधारा गया)

मैंने अभी थोड़ी खुदाई की है और ऐसा प्रतीत होता है कि परीक्षण 53-sim-binary_tree कोई इनपुट उत्पन्न नहीं कर रहा है और स्टैंडअलोन चलाने पर त्रुटि कोड 14/EFAULT के साथ लौट रहा है।

मैंने कुछ त्वरित उपकरण जोड़े (नीचे):

diff --git a/tests/53-sim-binary_tree.c b/tests/53-sim-binary_tree.c
index 2c7890e..c154f67 100644
--- a/tests/53-sim-binary_tree.c
+++ b/tests/53-sim-binary_tree.c
@@ -81,6 +81,7 @@ int main(int argc, char *argv[])
                                              SCMP_A0(SCMP_CMP_EQ, i));
                else
                        rc = seccomp_rule_add(ctx, SCMP_ACT_ERRNO(i), i, 0);
+               printf("PMD: i=%d, rc=%d\n", i, rc);
                if (rc < 0)
                        goto out;
        }

... जिसके परिणामस्वरूप निम्नलिखित आउटपुट हुआ:

# ./53-sim-binary_tree -p
PMD: i=0, rc=0
PMD: i=1, rc=0
PMD: i=2, rc=0
PMD: i=3, rc=0
...
PMD: i=161, rc=0
PMD: i=162, rc=0
PMD: i=163, rc=-14

दिलचस्प। माई रास्पबेरी पाई की कुछ महीने पहले मृत्यु हो गई थी, लेकिन यह एक नया ऑर्डर करने का एक अच्छा बहाना लगता है। नया 2GB संस्करण वास्तव में आकर्षक लग रहा है।

जब तक यह नहीं आता, मुझे Oracle के भीतर एक ARM मशीन खोजने में सक्षम होना चाहिए। मैं देखना शुरू करूँगा...

सुनने में तो अच्छा लगता है। मैं यह जानने के लिए उत्सुक हूं कि नया आरपीआई 4 कैसे करता है, मुझे केवल 3 बी मिला है।

भले ही, अगर आपको कोई सिस्टम नहीं मिल रहा है तो मुझे बताएं।

aarch64 की syscall तालिका कई स्थानों पर विरल है, और इस प्रकार aarch64_syscall_resolve_num() NULL लौटाता है यदि aarch64_syscall_table में syscall संख्या नहीं मिल पाती है।

यहाँ syscall संख्याओं की सटीक सूची है जो वर्तमान में aarch64 में मौजूद नहीं हैं:

                if (i == 163 || i == 164 || i == 244 || i == 245 ||
                    i == 246 || i == 247 || i == 248 || i == 249 ||
                    i == 250 || i == 251 || i == 252 || i == 253 ||
                    i == 254 || i == 255 || i == 256 || i == 257 ||
                    i == 258 || i == 259 || i >= 295)
                        /* aarch64 doesn't support these syscall numbers.
                         * remove them
                         */
                        continue;

मैं वास्तव में आगे बढ़ने के सर्वोत्तम तरीके के बारे में निश्चित नहीं हूं। क्या हमें परीक्षण 53 और 55 को केवल x86_64 तक सीमित करना चाहिए? मैं वास्तव में यह सुनिश्चित करना चाहता हूं कि हम बड़े, असंतुलित बाइनरी ट्री का परीक्षण कर रहे हैं। ऐसा लगता है कि इस तरह के मामले में हम इन परीक्षणों को छोड़ सकते हैं। या शायद हमें इन आर्किटेक्चर के लिए एक छोटा, सरल परीक्षण करना चाहिए।

विचार?

बमर। हालांकि एक फर्जी सिस्कल नंबर में खिलाना और वैध परिणाम की उम्मीद करना काफी उचित नहीं है;)

एक संभावना यह होगी कि पहले यह देखने के लिए seccomp_syscall_resolve_num_arch(SCMP_ARCH_NATIVE, i) पर कॉल करें कि क्या वह सिस्कल नंबर मौजूद है; यदि ऐसा नहीं होता है, तो आप बस उस गैर-मौजूद सिस्कल को छोड़ देते हैं।

मुझे लगता है कि यह भी ध्यान देने योग्य है कि यह विशुद्ध रूप से एक परीक्षण समस्या है और सामान्य aarch64 समस्या नहीं है। वास्तविक दुनिया में उचित परिणामों की अपेक्षा के साथ केवल वैध syscall नंबर API में फीड किए जाएंगे।

बमर। हालांकि एक फर्जी सिस्कल नंबर में खिलाना और वैध परिणाम की उम्मीद करना काफी उचित नहीं है;)

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

एक संभावना यह होगी कि पहले यह देखने के लिए seccomp_syscall_resolve_num_arch(SCMP_ARCH_NATIVE, i) पर कॉल करें कि क्या वह सिस्कल नंबर मौजूद है; यदि ऐसा नहीं होता है, तो आप बस उस गैर-मौजूद सिस्कल को छोड़ देते हैं।

मैंने इसके बारे में सोचा था, लेकिन इससे पूर्व-आबादी वाली *.pfc फ़ाइल के साथ तुलना करना वाकई मुश्किल हो जाता है जैसे हम परीक्षण 55 में कर रहे हैं।

मुझे लगता है कि यह भी ध्यान देने योग्य है कि यह विशुद्ध रूप से एक परीक्षण समस्या है और सामान्य aarch64 समस्या नहीं है। वास्तविक दुनिया में उचित परिणामों की अपेक्षा के साथ केवल वैध syscall नंबर API में फीड किए जाएंगे।

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

मैंने इसके बारे में सोचा, लेकिन इससे पूर्व-आबादी वाली *.pfc फ़ाइल के साथ तुलना करना वाकई मुश्किल हो जाता है जैसे हम परीक्षण 55 में कर रहे हैं।

शायद इसका उत्तर यह है कि परीक्षण 55 के लिए हम syscalls (एक दर्जन, दो दर्जन?) के एक छोटे उपसमुच्चय का उपयोग करते हैं जैसे कि हम syscall नाम से संख्या समाधान कर सकते हैं ताकि यह सुनिश्चित हो सके कि वे मौजूद हैं।

शायद इसका उत्तर यह है कि परीक्षण 55 के लिए हम syscalls (एक दर्जन, दो दर्जन?) के एक छोटे उपसमुच्चय का उपयोग करते हैं जैसे कि हम syscall नाम से संख्या समाधान कर सकते हैं ताकि यह सुनिश्चित हो सके कि वे मौजूद हैं।

हाँ, मुझे लगता है कि यह सबसे अच्छा और सबसे सुरक्षित उत्तर है। तो स्पष्ट रूप से aarch64 की syscall तालिका में 163 तक कोई छेद नहीं है। क्या आप जानते हैं कि अन्य आर्किटेक्चर की तालिकाएँ कैसी दिखती हैं?

और क्या हमें विश्वास है कि 24 या तो सिस्को का एक बाइनरी ट्री कोड का पूरी तरह से परीक्षण करता है? (शायद आपसे ज्यादा मेरे लिए एक सवाल है।) मेरी आंत महसूस कर रही है हाँ, लेकिन मैं इसे देखना चाहता हूं और इसे कवरऑल के माध्यम से भी चलाना चाहता हूं।

हाँ, मुझे लगता है कि यह सबसे अच्छा और सबसे सुरक्षित उत्तर है। तो स्पष्ट रूप से aarch64 की syscall तालिका में 163 तक कोई छेद नहीं है। क्या आप जानते हैं कि अन्य आर्किटेक्चर की तालिकाएँ कैसी दिखती हैं?

अगर केवल हमारे पास सिस्कल आर्किटेक्चर की पूर्व-निर्मित तालिका थी ... ओह रुको, हम करते हैं! ;)

उदाहरण aarch64 का उपयोग करते हुए, syscall संख्या द्वारा क्रमबद्ध:

# ./src/arch-syscall-dump -a aarch64 | sort -k2 -n

और क्या हमें विश्वास है कि 24 या तो सिस्को का एक बाइनरी ट्री कोड का पूरी तरह से परीक्षण करता है? (शायद आपसे ज्यादा मेरे लिए एक सवाल है।) मेरी आंत महसूस कर रही है हाँ, लेकिन मैं इसे देखना चाहता हूं और इसे कवरऑल के माध्यम से भी चलाना चाहता हूं।

एक परीक्षण जो अविश्वसनीय है, इसकी व्यापकता के स्तर की परवाह किए बिना उपयोगी नहीं है। मेरे पास एक "काफी अच्छा" परीक्षण होगा जो हमेशा सुसंगत होता है, हर जगह इसे चलाया जाता है, हर बार इसे चलाया जाता है जिसे हम बाद में बना सकते हैं।

अगर केवल हमारे पास सिस्कल आर्किटेक्चर की पूर्व-निर्मित तालिका थी ... ओह रुको, हम करते हैं! ;)

मुझे लगा कि उसके लिए एक उपकरण था। धन्यवाद ;)

एक परीक्षण जो अविश्वसनीय है, इसकी व्यापकता के स्तर की परवाह किए बिना उपयोगी नहीं है।

माना। मैं लालची हो गया और मुझे लगा कि मैं घरेलू परीक्षण बना सकता हूं। ओह ठीक है, इस मामले में "काफी अच्छा" परीक्षण पर्याप्त होना चाहिए। मैं आज इस पर काम करूंगा।

मैं लालची हो गया और मुझे लगा कि मैं घरेलू परीक्षण बना सकता हूं। ओह ठीक है, इस मामले में "काफी अच्छा" परीक्षण पर्याप्त होना चाहिए। मैं आज इस पर काम करूंगा।

अरे, कोई बात नहीं, हम सब समय-समय पर उस जाल में फँसते रहे हैं। यह अभी भी एक अच्छा सुधार है और हमारे पास कम से कम एक बुनियादी परीक्षण है; यह बहुत बुरा हो सकता

एफडब्ल्यूआईडब्ल्यू, यह पीपीसी 64 पर भी विफल रहता है:

बैच का नाम: 53-सिम-बाइनरी_ट्री
परीक्षण मोड: सी
परीक्षण प्रकार: बीपीएफ-सिम
परीक्षण 53-सिम-बाइनरी_ट्री%% 001-00001 परिणाम: त्रुटि 53-सिम-बाइनरी_ट्री आरसी = 14
परीक्षण 53-सिम-बाइनरी_ट्री%%002-00001 परिणाम: त्रुटि 53-सिम-बाइनरी_ट्री आरसी = 14
परीक्षण ५३-सिम-बाइनरी_ट्री%%००३-०००१ परिणाम: त्रुटि ५३-सिम-बाइनरी_ट्री आरसी = १४
परीक्षण 53-सिम-बाइनरी_ट्री%%004-00001 परिणाम: त्रुटि 53-सिम-बाइनरी_ट्री आरसी = 14
परीक्षण 53-सिम-बाइनरी_ट्री%%005-00001 परिणाम: त्रुटि 53-सिम-बाइनरी_ट्री आरसी = 14
परीक्षण 53-सिम-बाइनरी_ट्री%%006-00001 परिणाम: त्रुटि 53-सिम-बाइनरी_ट्री आरसी = 14
परीक्षण 53-सिम-बाइनरी_ट्री%%007-00001 परिणाम: त्रुटि 53-सिम-बाइनरी_ट्री आरसी = 14
परीक्षण 53-सिम-बाइनरी_ट्री%%008-00001 परिणाम: त्रुटि 53-सिम-बाइनरी_ट्री आरसी = 14
परीक्षण 53-सिम-बाइनरी_ट्री%%009-00001 परिणाम: त्रुटि 53-सिम-बाइनरी_ट्री आरसी = 14
परीक्षण 53-सिम-बाइनरी_ट्री%%010-00001 परिणाम: त्रुटि 53-सिम-बाइनरी_ट्री आरसी = 14
...
परीक्षण मोड: सी
परीक्षण प्रकार: बीपीएफ-वालग्रिंड
परीक्षण ५३-सिम-बाइनरी_ट्री%%३३१-०००१ परिणाम: विफलता ५३-सिम-बाइनरी_ट्री आरसी = १४

और 55-मूल-pfc_binary_tree भी:

बैच का नाम: 55-बेसिक-pfc_binary_tree
परीक्षण मोड: सी
परीक्षण प्रकार: मूल
परीक्षण 55-मूल-pfc_binary_tree%%001-00001 परिणाम: विफलता 55-मूल-pfc_binary_tree.sh rc=1

हाय @ पीसो77 , रिपोर्ट के लिए धन्यवाद। एक बार @drakenclimber के ठीक हो जाने के बाद क्या आप इसका परीक्षण करने के इच्छुक होंगे?

दुर्भाग्य से, मुझे लगता है कि कुछ अन्य एबीआई हो सकते हैं जिनमें समान विफलताएं हैं; यह केवल इतना है कि aarch64 एकमात्र गैर-x86 ABI है जिसे परीक्षण उद्देश्यों के लिए मेरे पास आसान पहुंच है। इस सूत्र में हम जिस सुधार पर चर्चा कर रहे हैं, वह इन सभी विफलताओं (मुझे लगता है) को संबोधित करना चाहिए।

मैंने प्रत्येक वास्तुकला में पहला छेद खोजने के लिए एक त्वरित पायथन लिपि लिखी ।

यहाँ परिणाम हैं:

$ ./find-first-hole-in-each-arch.py 
aarch64's first syscall number hole is 163
arm's first syscall number hole is 7
mips64's first syscall number hole is 1
mips64n32's first syscall number hole is 1
mips's first syscall number hole is 1
parisc64's first syscall number hole is 102
ppc64's first syscall number hole is 192
ppc's first syscall number hole is 224
riscv64's first syscall number hole is 38
s390's first syscall number hole is 17
s390x's first syscall number hole is 13
x32's first syscall number hole is 1
x86_64's first syscall number hole is 335

इन परिणामों के आधार पर, मुझे लगता है कि हमें syscall संख्या 12 पर सीमित करने के लिए परीक्षण 53 और 55 को कम करना चाहिए। ध्यान दें कि कुछ आर्किटेक्चर (मिप्स, आदि) हैं जो विफल हो जाएंगे, भले ही हम कितनी भी कम संख्या चुनें।

हाय @ पीसो77 , रिपोर्ट के लिए धन्यवाद। एक बार @drakenclimber के ठीक हो जाने के बाद क्या आप इसका परीक्षण करने के इच्छुक होंगे?

ज़रूर, जब कोई पैच उपलब्ध हो तो मुझे पिंग करें!

ध्यान दें कि कुछ आर्किटेक्चर (मिप्स, आदि) हैं जो विफल हो जाएंगे चाहे हम कितनी भी कम संख्या चुनें।

आप इसे कैसे संबोधित करने की योजना बना रहे हैं?

ध्यान दें कि कुछ आर्किटेक्चर (मिप्स, आदि) हैं जो विफल हो जाएंगे चाहे हम कितनी भी कम संख्या चुनें।

आप इसे कैसे संबोधित करने की योजना बना रहे हैं?

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

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

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

नोट: syscalls को उस विशेष ABI के लिए मान्य होने की आवश्यकता नहीं है, जब तक कि वे हमारी आंतरिक syscall तालिका में मान्य syscall नाम हैं।

मुझे यकीन नहीं है कि हमारे पास किसी अन्य परीक्षण के साथ प्राथमिकता है

मुझे लगता है आप सही हैं। यह एक विशेष स्थिति है।

मुझे लगता है कि इसे ठीक करने का सही तरीका सिस्कल नामों की सूची का उपयोग करना है, न कि संख्याओं का। यह परीक्षण में थोड़ा और काम है, लेकिन इसे शायद पूरी तरह से टालना चाहिए।

मैं इस विकल्प के साथ अच्छा हूँ। मुझे अभी तक यकीन नहीं है कि मैं इसे पीएफसी केस (टेस्ट 55) के लिए कैसे काम कर सकता हूं, लेकिन मैं इसे एक शॉट दूंगा!

यह पीआर # 211 में तय किया गया था और एक अनुवर्ती फिक्स जिसे मैंने dc2831e8fdcad71d565ba02abf732c8ffd260f66 के माध्यम से एक साथ (कोई पीआर नहीं) हैक किया था।