Libseccomp: बग: gen_bpf_generate() विफलता को ठीक से संभाल नहीं पाता

हाय @Xyene ,

ऐसे बहुत से स्थान नहीं हैं जो seccomp_load() कोड पथ में -EINVAL लौटाते हैं। libseccomp v2.4.3 कोड की त्वरित जांच के आधार पर ऐसा लगता है कि यह या तो एक अमान्य scmp_filter_ctx या कर्नेल prctl(...) कॉल के बारे में शिकायत कर रहा है जो फ़िल्टर लोड करता है।

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

हालांकि यह हमेशा संभव है कि गलती libseccomp के साथ है, हम प्रत्येक रिलीज को चेक की एक श्रृंखला के माध्यम से चलाते हैं जिसमें हमारे सभी प्रतिगमन परीक्षणों के साथ-साथ क्लैंग और कवरिटी दोनों का उपयोग करके स्थिर विश्लेषण के लिए वालग्रिंड रन शामिल हैं।

साथ ही, जबकि यह v2.4.3 के लिए मदद नहीं करता है, लगभग तैयार v2.5.0 रिलीज़ के लिए हम जिन सुधारों को लक्षित कर रहे हैं उनमें से एक सुधार दस्तावेज़ीकरण और त्रुटि कोड का प्रबंधन है।

हमने हाल ही में अपने डॉकर कंटेनरों में पैकेजों को अपग्रेड किया है, जिसमें libseccomp 2.3.3 (डेबियन स्टेबल रेपो में संस्करण) से 2.4.3 तक अपग्रेड शामिल है। अन्य सिस्टम पैकेज भी थे जो अपग्रेड हो गए, लेकिन मैंने उन्हें रिकॉर्ड नहीं किया। हमारा कर्नेल अपग्रेड नहीं किया गया था, और संस्करण 4.19.0-8-amd64 है।

यह सत्यापित करने के लिए धन्यवाद कि आपका कोड और अंतर्निहित कर्नेल नहीं बदला है। इससे समस्या को ट्रैक करने में मदद मिलनी चाहिए।

संदर्भ के लिए, यह seccomp_rule_add मैन पेज के समान त्रुटि-जांच का उपयोग करते हुए, हमारे seccomp आरंभीकरण दिनचर्या की संपूर्णता है।

आपका फ़िल्टर मुझे उचित लगता है।

क्या गलत हो सकता है (या यहां तक ​​​​कि क्या गलत हो रहा है में आगे खुदाई करने के लिए) पर कोई विचार, या यदि यह किसी तरह से अपेक्षित है? बहुत सारे गतिशील चलने वाले हिस्से नहीं हैं, और मुझे दस्तावेज़ीकरण में कुछ भी नहीं मिला कि ऐसा क्यों हो रहा है।

मैंने v2.4.3 seccomp_load() कोड के माध्यम से देखा, और मुझे लगता है कि केवल दो स्थान हैं जहां libseccomp -EINVAL का रिटर्न कोड उत्पन्न करता है:

• seccomp_load() लाइन 283 . पर
• _gen_bpf_build_bpf() लाइन पर

उपरोक्त दोनों त्रुटियां प्रभावी रूप से एक अमान्य फ़िल्टर के कारण होती हैं। आपके फ़िल्टर कोड के आधार पर यह मेरे लिए असंभव लगता है।

यह ध्यान देने योग्य है कि seccomp_set_mode_filter() में कर्नेल का डिफ़ॉल्ट रिटर्न मान -EINVAL , इसलिए यह संभव है कि सिस्टम पर कुछ और बदल गया, जिससे हम उस रास्ते पर गिर गए। आप उल्लेख करते हैं कि आप डॉकर में चल रहे हैं; क्या आप डिफ़ॉल्ट डॉकर seccomp फ़िल्टर अक्षम कर रहे हैं?

अगर seccomp_load() विफल होने के बाद मैं आपके कोड में कुछ और डिबगिंग जोड़ने का लुत्फ उठाऊंगा। उदाहरण के लिए, हम फिल्टर के पीएफसी और/या बीपीएफ को आउटपुट कर सकते हैं ताकि यह सत्यापित किया जा सके कि यह उचित है। seccomp_export_pfc() और seccomp_export_bpf() ।

मैंने v2.4.3 seccomp_load() कोड के माध्यम से देखा, और मुझे लगता है कि केवल दो स्थान हैं जहां libseccomp -EINVAL का रिटर्न कोड उत्पन्न करता है:

• seccomp_load() लाइन 283 . पर
• _gen_bpf_build_bpf() लाइन 1657 . पर

ध्यान रखें कि gen_bpf_generate(...) , या नीचे में पाई जाने वाली कोई भी विफलता, src/system.c:267 पर प्रभावी रूप से -ENOMEM में sys_filter_load(...) से संयोजित हो जाती है।

मुझे "स्मृति भ्रष्टाचार!" पर वापस आने से नफरत है। इतनी जल्दी, लेकिन ऐसा लगता है कि यहाँ ऐसा ही हो सकता है।

त्वरित और विस्तृत उत्तरों के लिए धन्यवाद! उन्होंने अन्वेषण के कई रास्ते तैयार किए हैं: थोड़ा_मुस्कुराते हुए_फेस:

क्या आपने अपग्रेड के बाद से अपने प्रोग्राम में कोई अन्य अजीब व्यवहार देखा है? मैं सोच रहा हूं कि कहीं और स्मृति भ्रष्टाचार समस्या है जो समस्या पैदा कर रही है।

नहीं, बस यही। हमारी इकाई और एकीकरण परीक्षण जारी हैं, और इस दुर्लभ EINVAL , उत्पादों में कोई त्रुटि लॉग नहीं की जा रही है। यह निश्चित रूप से इसे हैरान करता है; मुझे स्मृति भ्रष्टाचार पर भी संदेह था, लेकिन इसका समर्थन करने के लिए कोई सबूत नहीं मिला: थोड़ा_फ्राइंग_फेस:

थोड़ा और संदर्भ के लिए:

• कार्यक्रम एक पायथन ऐप है जो साइथन के माध्यम से कुछ सी ++ में कॉल कर रहा है (जीआईएल इस समय के दौरान आयोजित किया जाता है, इसलिए पायथन अन्य धागे पर आवंटन नहीं कर रहा है)
• सी ++ साइड फोर्क, और बच्चे में निष्पादन से पहले सेकम्प फ़िल्टर सेट करता है
• फोर्क के बाद होने वाली सभी मेमोरी आवंटन, पूर्व-निष्पादन libseccomp से ही हैं, seccomp_init आदि में।
• सी ++ कोड में कॉल करने और फोर्किंग के बीच ठीक

इसे टाइप करते समय मुझे एक विचार आया: मैंने malloc बारे में डरावनी कहानियां सुनी हैं जो फोर्किंग के बाद उपयोग करने के लिए असुरक्षित हैं, और हमारे पास कुछ libseccomp के भीतर ही है। पायथन ऐप ही _is_ मल्टीथ्रेडेड है, लेकिन हम हमेशा देशी कोड में रहते हुए GIL को होल्ड करते हैं, इसलिए यह सुरक्षित (?) होना चाहिए। मैंने केवल मॉलोक-आफ्टर-फोर्क के माध्यम से होने वाले गतिरोध के बारे में सुना है, हालाँकि। (मुझे लगता है कि यह व्यापार का अगला क्रम seccomp_init et al। कांटे से पहले, केवल seccomp_load पोस्ट-फोर्क को कॉल करता है, और देखता है कि त्रुटियां हो रही हैं या नहीं।)

अगर seccomp_load() विफल होने के बाद मैं आपके कोड में कुछ और डिबगिंग जोड़ने का लुत्फ उठाऊंगा।

सलाह के लिये धन्यवाद! मैंने seccomp_export_pfc एक कॉल जोड़ा है, साथ ही इनपुट की सामग्री को फ़िल्टर ( config->syscall_whitelist ) में डंप किया है। अगली बार यह विफल होने पर मैं अनुवर्ती कार्रवाई करूंगा।

नमस्ते @Xyene - चूंकि लगभग एक सप्ताह हो गया है, मैं बस जांचना और देखना चाहता था कि क्या कुछ नया है जो आपको मिला है?

अभी नहीं, दुर्भाग्य से। पैच में जोड़ने के बाद seccomp_export_pfc , यह चुप हो गया है। कल मैंने उस पैच को हमारे सभी VMs (केवल एक परीक्षण के बजाय) पर धकेल दिया, जब यह अंततः होता है तो इस मुद्दे को पकड़ने की उम्मीद में।

मुझे चुप्पी अजीब लगती है, लेकिन अभी के लिए मैं इसे संयोग के लिए तैयार कर रहा हूं क्योंकि सभी डिबगिंग/निर्यात तर्क _after_ विफल seccomp_load , इसलिए इसे विफलता को प्रभावित नहीं करना चाहिए।

प्रगति!

यह चुप रहने का कारण बताता है क्योंकि seccomp_export_bpf segfaulting था (क्या इसे seccomp_load बाद बुलाया जाना चाहिए?), और यह कहीं और रिपोर्ट किया जा रहा था, न कि जहां मैं seccomp विफलताओं की तलाश में था। सबसे महत्वपूर्ण बात यह है कि मैंने ऐसे मामले में भाग लिया है जहां मैं इस मुद्दे को ~ 150 आमंत्रणों में विश्वसनीय रूप से पुन: उत्पन्न कर सकता हूं, इसलिए कुछ नलसाजी कार्य के साथ मुझे कुछ कोर डंप निकालने में सक्षम होना चाहिए।

ठीक है, मैंने एक कोरडम्प निकाला, और यह ट्रेस था: https://gist.github.com/Xyene/920f1cb098784a031f53c66a2f49d167

यह थोड़ा संदिग्ध था, क्योंकि यह जेमलोक के realloc रूटीन के अंदर दुर्घटनाग्रस्त हो रहा है। इसके अलावा, इसके बजाय ग्लिब मॉलोक का उपयोग करने से समस्या हल हो जाती है (दुर्भाग्य से, यह विखंडन मुद्दों के कारण इस मामले में दीर्घकालिक विकल्प नहीं है)।

इसके बाद, मैंने जेमलोक में खींचा, इसे -O0 और डिबगिंग प्रतीकों के साथ संकलित किया, और प्रजनन को फिर से चलाया। इस बार यह बाद के बजाय seccomp_load में दुर्घटनाग्रस्त हो गया! मैंने उस ट्रेस को यहां अपलोड किया है: https://gist.github.com/Xyene/5da56168bea337da85b2cd30704d12e

उस ट्रेस का एक अंश:

#9  0x00007ff962698495 in free (ptr=0x5a5a5a5a5a5a5a5a) at src/jemalloc.c:2867
No locals.
#10 0x00007ff96062d087 in _program_free (prg=prg@entry=0x7ff95e963010) at gen_bpf.c:511
No locals.
#11 0x00007ff96062f605 in gen_bpf_release (program=program@entry=0x7ff95e963010) at gen_bpf.c:1986
No locals.
#12 0x00007ff96062c04f in sys_filter_load (col=col@entry=0x7ff95e9a5000) at system.c:293
        rc = -1
        prgm = 0x7ff95e963010
#13 0x00007ff96062b666 in seccomp_load (ctx=ctx@entry=0x7ff95e9a5000) at api.c:286
        col = 0x7ff95e9a5000

जेमलोक को खोजते हुए, ऐसा लगता है कि 0x5a का उपयोग फ्री बाइट्स को फ्री के रूप में चिह्नित करने के लिए किया जाता है , क्रैशिंग कोड के विशिष्ट उद्देश्य के साथ जो पहले से ही मुक्त की गई किसी चीज को मुक्त करने का प्रयास कर रहा है।

gen_bpf.c:511 v2.4.3 में है: https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/gen_bpf.c#L505 -L513

लेकिन, इसका कोई मतलब नहीं है क्योंकि कार्यक्रम का जीवनकाल केवल sys_filter_load का शरीर है:

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/system.c#L260 -L296

मुझे लगता है कि मैंने कम से कम एक मुद्दा देखा है। gen_bpf_generate ;

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/gen_bpf.c#L1963 -L1966

state.bpf = prgm जब तक zmalloc विफल नहीं हुआ। इसके बाद, _gen_bpf_build_bpf को कॉल किया जाता है, और इसके rc , state.bpf को NULL सेट किया जाता है।

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/gen_bpf.c#L1968 -L1971

इस मामले में जहां ध्यान में रखते rc != 0 , state.bpf अभी भी करने के लिए सेट कर दिया जाता prgm करने के लिए कॉल के समय _state_release । इससे स्मृति को prgm द्वारा मुक्त करने के लिए इंगित किया जाएगा।

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/gen_bpf.c#L539

अगला, gen_bpf_generate होगा return prgm , जो मुक्त होने के बावजूद, अभी भी एक गैर-शून्य सूचक है।

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/gen_bpf.c#L1971 -L1974

वापस sys_filter_load , gen_bpf_generate रिटर्न, और prgm नहीं है- NULL इसलिए यह जारी है।

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/system.c#L265 -L267

अंत में, sys_filter_load के अंत में, gen_bpf_release पहले से मुक्त prgm पर कॉल किया जाता है।

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/system.c#L292 -L295

यह इस चिंता का समाधान नहीं करता है कि क्यों _gen_bpf_build_bpf पहली बार में विफल हो जाएगा, लेकिन ऐसा कुछ बुरा लगता है जो ऐसा होने पर हो सकता है।

संपादित करें: वास्तव में, ऐसा लगता है कि यह संभवतः https://github.com/seccomp/libseccomp/commit/3a1d1c977065f204b96293cccfe7d3e5aa0d7ace के दुष्प्रभाव के रूप में तय किया गया था

उस मामले को ध्यान में रखते हुए जहां _state_release पर कॉल के समय rc != 0, State.bpf अभी भी prgm पर सेट है। इससे prgm द्वारा बताई गई मेमोरी मुक्त हो जाएगी।

आह हा! अच्छा कैच @Xyene!

मुझे लगता है कि हमें इसे 3a1d1c977065f204b96293cccfe7d3e5aa0d7ace से आगे ठीक करने की आवश्यकता है, मुझे इस पर एक मिनट के लिए सोचने दें ... मुझे नहीं लगता कि फिक्स बहुत कठिन होगा ... और देखें कि क्या मैं पीआर के साथ आ सकता हूं।

मुझे लगता है कि हमें इसे 3a1d1c9 से आगे ठीक करने की आवश्यकता है, मुझे इस पर एक मिनट के लिए सोचने दें ... मुझे नहीं लगता कि फिक्स बहुत कठिन होगा ... और देखें कि क्या मैं पीआर के साथ आ सकता हूं।

ओह, जब मैंने लिखा था तो मैं पुराना कोड देख रहा था; हां, मेरा मानना ​​है कि 3a1d1c9 हमारे लिए इसे ठीक करता है, लेकिन हमें रिलीज-2.4 शाखा के लिए एक पैच की आवश्यकता होगी। मैं अब उस पर काम करूंगा।

_(मेटा: जैसे-जैसे मैं आगे बढ़ूंगा, मैं इस संदेश को अपने निष्कर्षों के साथ अपडेट करना जारी रखूंगा, इसलिए मेरे पास आप लोगों को ईमेल किए बिना उन्हें लिखने के लिए कहीं है :)_

ठीक है, 2.4.3 पर वापस पैच लागू होने के साथ, मैं उस फ़िल्टर को बाहर निकालने में सक्षम हूं जो विफल हो रहा था: लिंक ।

रिपोर्ट किया गया कारण अब ENOMEM बजाय EINVAL , जो मुझे लगता है कि यह अपेक्षित है कि _gen_bpf_build_bpf विफल हो रहा है और NULL प्रोग्राम लौटा रहा है। हालांकि, पीएफसी ठीक प्रिंट करता है। Seccomp कोड संशोधित करने के रिटर्न मान रिपोर्ट करने के लिए _gen_bpf_build_bpf शो EFAULT कारण के रूप में।

एक त्वरित हैक के रूप में मैं :%s/return -EFAULT/abort() से अधिक src/gen_bpf.c , और इस स्टैक ट्रेस को निकालने में सक्षम था:

(gdb) bt full
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = {__val = {0, 140084028365964, 140083248439464, 140083248438968, 140083248431088, 140084028368143, 28659884033, 140083965300736, 
            140083248439464, 140083248438968, 140083248431088, 140084028351031, 140084019988760, 140083248439624, 140083248431200, 140084028372597}}
        pid = <optimized out>
        tid = <optimized out>
        ret = <optimized out>
#1  0x00007f67daa4d55b in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x7f67d6f3eec0, sa_sigaction = 0x7f67d6f3eec0}, sa_mask = {__val = {140083965300736, 
              140083965300736, 0, 0, 140083248438968, 140083248438968, 140083248439464, 140083248431504, 140084028417173, 140083964793344, 
              140083965300736, 140083248431552, 140083994791895, 140083248431552, 140083994787642, 140083965300736}}, sa_flags = -1404894496, 
          sa_restorer = 0x0}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007f67d8bfd455 in _gen_bpf_build_bpf (state=0x7f67ac4302e0, col=0x7f67d6f63040) at gen_bpf.c:1943
        rc = 0
        iter = 1
        h_val = 1425818561
        res_cnt = 0
        jmp_len = 0
        arch_x86_64 = 0
        arch_x32 = -1
        instr = {op = 32, jt = {tgt = {imm_j = 0 '\000', imm_k = 0, hash = 0, db = 0x0, blk = 0x0, nxt = 0}, type = TGT_NONE}, jf = {tgt = {
              imm_j = 0 '\000', imm_k = 0, hash = 0, db = 0x0, blk = 0x0, nxt = 0}, type = TGT_NONE}, k = {tgt = {imm_j = 4 '\004', imm_k = 4, 
              hash = 4, db = 0x4, blk = 0x4, nxt = 4}, type = TGT_K}}
        i_iter = 0x7f67d6fdcb60
        b_badarch = 0x7f67d6fd9000
        b_default = 0x7f67d6fd9060
        b_head = 0x7f67d6fda1a0
        b_tail = 0x7f67d6fd9000
        b_iter = 0x0
        b_new = 0x7f67d6fe3300
        b_jmp = 0x0
        db_secondary = 0x0
        pseudo_arch = {token = 0, token_bpf = 0, size = ARCH_SIZE_UNSPEC, endian = ARCH_ENDIAN_LITTLE, syscall_resolve_name = 0x0, 
          syscall_resolve_num = 0x0, syscall_rewrite = 0x0, rule_add = 0x0}
#3  0x00007f67d8bfd560 in gen_bpf_generate (col=0x7f67d6f63040) at gen_bpf.c:1971
        rc = 0
        state = {htbl = {0x0 <repeats 256 times>}, attr = 0x7f67d6f63044, bad_arch_hsh = 889798935, def_hsh = 742199527, arch = 0x7f67ac4301e0, 
          bpf = 0x7f67d6f64010}
        prgm = 0x7f67d6f64010
#4  0x00007f67d8bf64a7 in sys_filter_load (col=0x7f67d6f63040) at system.c:265
        rc = 32615
        prgm = 0x0
#5  0x00007f67d8bf4f10 in seccomp_load (ctx=0x7f67d6f63040) at api.c:287
        col = 0x7f67d6f63040

यह लाइन 1943 से मेल खाती है:

https://github.com/seccomp/libseccomp/blob/1dde9d94e0848e12da20602ca38032b91d521427/src/gen_bpf.c#L1935 -L1943

प्रतिस्थापन की प्रकृति को देखते हुए, मुझे लगता है कि हम किसी भी सहायक समारोह में किसी भी EFAULT को बाहर कर सकते हैं, क्योंकि वे पहले निरस्त हो जाते।

इसके बाद, मैंने इसे HEAD के साथ पुन: प्रस्तुत करने का प्रयास किया - यह अभी भी होता है। अगला, %s:/goto build_bpf_free_blks/abort() और दोहराएं। कारण था:

https://github.com/seccomp/libseccomp/blob/34bf78abc9567b66c72dbe67e7f243072162a25f/src/gen_bpf.c#L2219 -L2220

शुक्र है कि यह फ़ंक्शन छोटा था, और इसमें केवल कुछ ही विफलता बिंदु थे। बाद में abort प्रविष्टि का एक और दौर;

(gdb) bt full
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = {__val = {0, 140050183343588, 0, 448, 140049402494880, 140049402509040, 140049402494832, 140050183342988, 140049402495088, 
            140049402509040, 140049402494896, 140050183343588, 4294967296, 140049402509040, 140049402509040, 140049402509040}}
        pid = <optimized out>
        tid = <optimized out>
        ret = <optimized out>
#1  0x00007f5ff953055b in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x7f5ff595d260, sa_sigaction = 0x7f5ff595d260}, sa_mask = {__val = {139642271694862, 
              140050119389792, 0, 0, 140049402502840, 0, 140049402503336, 140049402502888, 140049402502840, 112, 384, 140049402502840, 140050149861504, 
              140049402495328, 140050149857273, 392}}, sa_flags = 448, sa_restorer = 0x7f5ff595d240}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007f5ff76edee5 in _bpf_append_blk (prg=0x7f5ff5964010, blk=0x7f5ff59df1a0) at gen_bpf.c:452
        rc = -12
        i_new = 0x0
        i_iter = 0x7f5ff59fa178
        old_cnt = 48
        iter = 1
#3  0x00007f5ff76f3716 in _gen_bpf_build_bpf (state=0x7f5fcae302d0, col=0x7f5ff59c5000) at gen_bpf.c:2223
        rc = 0
        iter = 1
        h_val = 1425818561
        res_cnt = 0
        jmp_len = 0
        arch_x86_64 = 0
        arch_x32 = -1
        instr = {op = 32, jt = {tgt = {imm_j = 0 '\000', imm_k = 0, hash = 0, db = 0x0, blk = 0x0, nxt = 0}, type = TGT_NONE}, jf = {tgt = {
              imm_j = 0 '\000', imm_k = 0, hash = 0, db = 0x0, blk = 0x0, nxt = 0}, type = TGT_NONE}, k = {tgt = {imm_j = 4 '\004', imm_k = 4, 
              hash = 4, db = 0x4, blk = 0x4, nxt = 4}, type = TGT_K}}
        i_iter = 0x7f5ff59e1b60
        b_badarch = 0x7f5ff59de000
        b_default = 0x7f5ff59de060
        b_head = 0x7f5ff59df1a0
        b_tail = 0x7f5ff59de000
        b_iter = 0x7f5ff59df1a0
        b_new = 0x7f5ff59e8300
        b_jmp = 0x7f5ff59df0e0
        db_secondary = 0x0
        pseudo_arch = {token = 0, token_bpf = 0, size = ARCH_SIZE_UNSPEC, endian = ARCH_ENDIAN_LITTLE, syscall_resolve_name = 0x0, 
          syscall_resolve_num = 0x0, syscall_rewrite = 0x0, rule_add = 0x0}
#4  0x00007f5ff76f3874 in gen_bpf_generate (col=0x7f5ff59c5000, prgm_ptr=0x7f5fcae30b40) at gen_bpf.c:2270
        rc = 0
        state = {htbl = {0x0, 0x7f5ff593ef80, 0x7f5ff593efe0, 0x7f5ff593efc0, 0x0, 0x7f5ff595d000, 0x7f5ff593ef60, 0x7f5ff593ef00, 
            0x0 <repeats 248 times>}, attr = 0x7f5ff59c5004, bad_arch_hsh = 889798935, def_hsh = 742199527, bpf = 0x7f5ff5964010, 
          arch = 0x7f5fcae301c0, b_head = 0x7f5ff59e8300, b_tail = 0x7f5ff59de120, b_new = 0x7f5ff59e8300}
        prgm = <optimized out>
#5  0x00007f5ff76eb275 in sys_filter_load (col=0x7f5ff59c5000, rawrc=false) at system.c:307
        rc = 0
        prgm = 0x0
#6  0x00007f5ff76e9505 in seccomp_load (ctx=0x7f5ff59c5000) at api.c:386
        col = 0x7f5ff59c5000
        rawrc = false

https://github.com/seccomp/libseccomp/blob/34bf78abc9567b66c72dbe67e7f243072162a25f/src/gen_bpf.c#L449 -L452

तो यह है realloc फिर से नाकाम रहने के लिए, और _bpf_append_blk लौटा रहा है -ENOMEM कि के नीचे दब जाता है _gen_bpf_build_bpf और में बदल गया -EFAULT । यह कोई बड़ी बात नहीं है, लेकिन चूंकि आपने कहा है कि बेहतर त्रुटि रिपोर्टिंग 2.5 का लक्ष्य है, मुझे लगा कि मैं इसका उल्लेख करूंगा क्योंकि यह इस दायरे में दिखता है: थोड़ा_स्माइलिंग_फेस:

GDB के साथ कुछ प्रहार:

(gdb) f 2
#2  0x00007f5ff76edee5 in _bpf_append_blk (prg=0x7f5ff5964010, blk=0x7f5ff59df1a0) at gen_bpf.c:452
452         abort();
(gdb) info args
prg = 0x7f5ff5964010
blk = 0x7f5ff59df1a0
(gdb) print prg->blks
$4 = (bpf_instr_raw *) 0x7f5ff59fa000
(gdb) x/32bx &prg->blks
0x7f5ff5964018: 0x00    0xa0    0x9f    0xf5    0x5f    0x7f    0x00    0x00
0x7f5ff5964020: 0x5a    0x5a    0x5a    0x5a    0x5a    0x5a    0x5a    0x5a
0x7f5ff5964028: 0x5a    0x5a    0x5a    0x5a    0x5a    0x5a    0x5a    0x5a
0x7f5ff5964030: 0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
(gdb) print ((prg)->blk_cnt * sizeof(*((prg)->blks)))
$5 = 392
(gdb) print prg->blk_cnt
$6 = 49

यह वास्तव में एक आवंटक विफलता की तरह दिखने लगता है ...

आह, यह कहानी अंत में अपने _थ्रिलिंग_ निष्कर्ष पर पहुंच गई है - मुझे पता चल गया है कि क्या हो रहा है, और एक सुधार सत्यापित किया है: थोड़ा_स्माइलिंग_फेस:

चूंकि यह एक दिलचस्प कहानी बना सकता है, यहाँ यह है:

मुख्य प्रक्रिया जो कार्यकर्ता को काटती है वह आमतौर पर ~ 80mb RSS पर बैठती है। इसके कांटे के बाद, यह स्मृति उपयोग को rlimit माध्यम से प्रतिबंधित करता है, कभी-कभी 64 एमबी तक। यह इसे उस स्थिति में रखता है जहां इसका वर्तमान मेमोरी उपयोग इसकी सीमा से अधिक है, लेकिन इसकी अनुमति है rlimit । _अधिकांश_ समय, मेमोरी आवंटक के पास कर्नेल से अधिक अनुरोध किए बिना libseccomp के आरंभीकरण रूटीन की सेवा के लिए पर्याप्त खाली मेमोरी होगी। लेकिन जब यह _नहीं_ करता है, और एक अतिरिक्त क्षेत्र या कुछ के लिए स्थान का अनुरोध करने की आवश्यकता होती है, तो कर्नेल इसे प्रदान नहीं करेगा क्योंकि प्रक्रिया पहले से ही अपनी सीमा से अधिक है।

2.4.3 में, स्मृति प्राप्त करने में यह विफलता EINVAL में प्रकट हुई और एक डबल-फ्री। मास्टर पोस्ट में- https://github.com/seccomp/libseccomp/commit/3a1d1c977065f204b96293cccfe7d3e5aa0d7ace , इसके बजाय EFAULT की सूचना दी गई है। https://github.com/seccomp/libseccomp/pull/257 लागू होने के साथ, ENOMEM सही ढंग से रिपोर्ट किया गया है।

ऐसा बहुत कम होने का कारण स्पष्ट हो जाता है: यह पूरी तरह से इस बात पर निर्भर करता है कि क्या आवंटक के पास कर्नेल से अधिक अनुरोध किए बिना बीपीएफ प्रोग्राम बनाने के लिए पर्याप्त मेमोरी है। विखंडन के निर्माण की अनुमति देने के बारे में ग्लिब का आवंटक अधिक ढीला है, इसलिए इसके साथ ऐसा कभी नहीं हुआ। jemalloc सख्त सीमा रखता है, और seccomp_load दौरान स्मृति का अनुरोध करने की आवश्यकता की बढ़ती संभावना की ओर जाता है - परिणामी विफलताओं को नोटिस करने के लिए पर्याप्त है, लेकिन फिर भी ट्रैक करने के लिए क्रोधित हो रहा है।

फिर, सभी setrlimit कॉल को _after_ seccomp_load पर ले जाने के लिए फिक्स बस है। ऐसा करने पर, realloc अब _bpf_append_blk में विफल नहीं होता है, और फ़िल्टर सफलतापूर्वक लोड हो जाता है। इसका मतलब यह है कि फ़िल्टर को अनुमति देने की आवश्यकता है setrlimit , लेकिन मेरे मामले में यह स्वीकार्य था। अधिक सामान्यतः, मुझे लगता है कि यह समस्या https://github.com/seccomp/libseccomp/issues/123 जैसी किसी चीज़ से हल हो जाएगी

@pcmoore , @drakenclimber - इस मुद्दे को डीबग करने में आपकी सभी मदद के लिए फिर से धन्यवाद! मुझे खुशी है कि मैं इसे अब अपने पीछे रख सकता हूं, लेकिन आपके संकेत वहां पहुंचने में अमूल्य थे: स्माइली:

इस बग को https://github.com/seccomp/libseccomp/commit/c0a6e6fd15f74c429a0b74e0dfd4de5a29aaebd द्वारा ठीक किया गया था