Libseccomp: बग: ओपनएमपी के साथ संगतता

नोट: मैंने अभी तक आपके परीक्षण मामले को नहीं देखा है, मैं आपके अच्छे लिखित विवरण के आधार पर अनुमान लगा रहा हूं

इसकी बहु-थ्रेडेड प्रकृति को ध्यान में रखते हुए, क्या आपने कर्नेल में फ़िल्टर लोड करने से पहले SCMP_FLTATR_CTL_TSYNC फ़िल्टर विशेषता को सत्य पर सेट करने का प्रयास किया है?

• http://man7.org/linux/man-pages/man3/seccomp_attr_set.3.html

मैंने SCMP_FLTATR_CTL_TSYNC सेट नहीं किया क्योंकि मैं थ्रेड में विभाजित होने से पहले seccomp फ़िल्टर जोड़ता हूं। इस प्रकार, कर्नेल को वैसे भी सभी थ्रेड्स पर फ़िल्टर लागू करना चाहिए (और जाहिर तौर पर यह ऐसा करता है)। टेस्टकेस में SCMP_FLTATR_CTL_TSYNC जोड़ने से कोई फर्क नहीं पड़ता (जो कि पैडेंटिक एरर हैंडलिंग, बीटीडब्ल्यू के साथ 100 से कम लाइन है)।

ठीक है, मैं बस इसका उल्लेख करना चाहता था; ऐसा लगता है कि आप चीजों को सही तरीके से कर रहे हैं (नए धागे पैदा करने से पहले फ़िल्टर सेट करना)। मुझे करीब से देखना होगा, लेकिन हो सकता है कि मुझे बहुत जल्द ऐसा करने का मौका न मिले।

इस बात की पुष्टि मेरे लिए काफी है कि मैं चीजों को स्पष्ट रूप से गलत नहीं कर रहा हूं। पर्याप्त समय लो!

सिंगल-थ्रेडेड उदाहरण में, ./seccomp_omp -t 1 -k 0 , openmp पहचानता है कि केवल एक थ्रेड चलने वाला है, इसलिए openmp उस सिंक्रोनाइज़ेशन को बायपास करता है जो वह आमतौर पर लूप के लिए मल्टी-थ्रेडेड में करता है। मैंने कर्नेल में seccomp_run_filters() में संसाधित किए गए syscalls को देखकर इसे सत्यापित किया। जैसा कि कोई उम्मीद करेगा, मैंने __NR_write() और __NR_madvise() पर एक कॉल देखी, जिसने seccomp को कर्नेल को थ्रेड को मारने का निर्देश देने के लिए प्रेरित किया।

बहु-थ्रेडेड उदाहरण में, ./seccomp_omp -t 2 -k 0 , openmp लूप के लिए समानांतर करने का प्रयास करता है। इस प्रकार ओपनएमपी लाइब्रेरी का बहुत अधिक उपयोग किया जाता है। यह तब स्पष्ट होता है जब seccomp_run_filters() के माध्यम से फिर से syscalls देखते हैं। __NR_mmap(), __NR_mprotect(), __NR_clone(), __NR_futex(), और अधिक syscalls को madvise() पर कॉल करने से पहले कॉल किया जाता है। अंतत: दो धागों में से एक अंतत: मैडविस () कहता है और seccomp उस धागे को ठीक से मारता है। लेकिन ओपनएमपी में थ्रेड्स के बीच सिंक्रोनाइज़ेशन होता है और इससे पहले कि दूसरा थ्रेड मैडविज़ () (और मारे जाएँ) को कॉल कर सकता है, दूसरा थ्रेड फ़्यूटेक्स () को कॉल करता है क्योंकि यह डेड थ्रेड से किसी चीज़ की प्रतीक्षा कर रहा है। और यही कारण है कि कार्यक्रम लटका हुआ है। एक धागा मारा गया है और दूसरा धागा डेटा (मृत धागे से) की प्रतीक्षा कर रहा है जो कभी नहीं आएगा।

मैंने ओपनएमपी के साथ ज्यादा काम नहीं किया है, लेकिन समानांतर ब्लॉक में सिग्नल पर कुछ चर्चा [ १ , २ , ३ , ...] होती है। अंतत: यह एक कठिन समस्या की तरह लगता है जिससे बचना सबसे अच्छा होगा।

ऐसा लगता है कि कुछ संभावित आसान समाधान हैं:

1. अपने डिफ़ॉल्ट हैंडलर के रूप में SCMP_ACT_KILL उपयोग न करें। इसके बजाय, इसके बजाय एक त्रुटि कोड का उपयोग करने के लिए स्विच करें, उदाहरण के लिए SCMP_ACT_ERROR(5) । मैंने आपके उदाहरण कार्यक्रम में यह परिवर्तन किया है, और सत्यापित किया है कि यह ठीक से समाप्त हो गया है।

2. यदि आपको ओपनएमपी की शक्ति की आवश्यकता नहीं है, तो दूसरा विकल्प pthread_create() या fork() जैसे अधिक सामान्य समाधान का उपयोग करने के लिए स्विच करना हो सकता है।

@drakenclimber तो ऐसा लगता है कि समस्या वास्तव में सिर्फ ओपनएमपी अतिरिक्त सिस्को बना रही है जो आमतौर पर फ़िल्टर का हिस्सा नहीं हो सकती है? या वह एक बड़ा बिंदु याद कर रहा है?

@drakenclimber अपना समय निवेश करने के लिए बहुत-बहुत धन्यवाद। एक मृत धागे की प्रतीक्षा लक्षणों की व्याख्या करती है।

अधिक संदर्भ देने के लिए: मैं वैज्ञानिक कोड लिखता हूं, इस प्रकार मैं ओपनएमपी के साथ चीजों को सरल रखना पसंद करता हूं। हालाँकि, मैं अपने उपयोगकर्ताओं को स्वयं से भी सुरक्षित रखना चाहता हूँ। इस प्रकार यदि मेरा कार्यक्रम सामान्य से कुछ भी अलग करता है, तो बस इसे परमाणु बनाएं। मैं अनुमान लगा रहा हूं, मैं अंततः जो हासिल करना चाहता हूं वह कुछ हद तक उचित त्रुटि संदेश के साथ प्रक्रिया (# 96) को मारना है।

क्या मूल्य मैं में errno के लिए उपयोग करना चाहिए SCMP_ACT_ERROR बारीकी से नकल करने के लिए SECCOMP_RET_KILL_PROCESS ? क्या ऐसा कुछ है जो सभी सिस्को में ठीक काम करता है?

@pcmoore - थोड़े। लेकिन मुझे लगता है कि बड़ा मुद्दा यह है कि ओपनएमपी अपने समानांतर निर्माण के अंदर संकेतों को अच्छी तरह से संभाल नहीं पाता है। मुझे लगता है कि यह डिजाइन द्वारा है।

@kloetzl - कोई चिंता नहीं - आप पूरी तरह से

ctx = seccomp_init(SCMP_ACT_ERRNO(ENOTBLK));
...
bool kill_process = false;
int rc;
#pragma omp parallel for num_threads(THREADS)
  for (int i = 0; i < THREADS * 2; i++) {
    fprintf(stderr, "%u\n", func(i));
    if (i == K) {
      rc = madvise(NULL, 0, 0); 
      if (rc < 0)
        kill_process = true;
      }   
    // sleep(10);
  }

  if (kill_process)
    goto error;

  seccomp_release(ctx);
  return 0;
error:
  seccomp_release(ctx);
  return -1; 
}

किस त्रुटि के लिए SCMP_ACT_ERRNO() वापस आना चाहिए, यह वास्तव में आप पर निर्भर है। SCMP_ACT_ERRNO() सभी syscalls पर काम करेगा। और आपका प्रोग्राम इसे संभालने वाला होगा और उपयोगकर्ता को एक त्रुटि वापस लौटाएगा, ताकि आप चुन सकें कि आपके लिए सबसे अच्छा कौन सा काम करता है। वास्तव में, एक अस्पष्ट चुनना - ENOTBLK कहें - एक तरीका हो सकता है कि आप जानते हैं कि त्रुटि seccomp कॉल को अवरुद्ध करने से आई है।

tl; dr - समांतर लूप में समस्या का पता लगाएं, लेकिन लूप के पूरा होने तक इसे संभालने की प्रतीक्षा करें। असफल सिस्कल के कारण आपको लूप के भीतर अतिरिक्त रक्षात्मक कोडिंग जोड़ने की आवश्यकता हो सकती है।

@kloetzl - मैं # 96 अंक देखूंगा और देख सकता हूं कि

और आपका प्रोग्राम इसे संभालने वाला होगा और उपयोगकर्ता को एक त्रुटि वापस लौटाएगा, ताकि आप चुन सकें कि आपके लिए सबसे अच्छा कौन सा काम करता है। वास्तव में, एक अस्पष्ट को चुनना - ENOTBLK कहें - एक तरीका हो सकता है कि आप जानते हैं कि त्रुटि seccomp कॉल को अवरुद्ध करने से आई है।

बात यह है कि, madvise को malloc की आंत में गहरा कहा जाता है। इस प्रकार, मैं त्रुटि को संभालने वाला नहीं हूं, ग्लिबैक है। तो सवाल यह है कि क्या ग्लिबैक (और सिस्कल करने वाले अन्य सभी पुस्तकालय) जानते हैं कि एक सिस्कल अपने मैन पेज में दी गई अन्य त्रुटियों को वापस कर सकता है और इसे उचित तरीके से संभाल सकता है?

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

आह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्ह्च्चा. मुझे यह सुनिश्चित करने के लिए ग्लिबैक कोड देखना होगा, लेकिन मैं निम्नलिखित अनुमानों को खतरे में डालने के लिए तैयार हूं:

• यदि madvise एक त्रुटि देता है, तो glibc _निश्चित रूप से एक त्रुटि भी लौटाएगा
• यह निश्चित रूप से संभव है कि ग्लिबैक सेककॉम्प की तुलना में एक अलग त्रुटि लौटा सकता है, इस प्रकार आपको सावधानी बरतनी चाहिए यदि आप ENOTBLK जैसे "कस्टम" रिटर्न कोड की अपेक्षा कर रहे हैं।

लंबी कहानी छोटी, ग्लिबक को _any_ त्रुटि कोड को दबाना नहीं चाहिए, लेकिन यह इसके बजाय एक अलग त्रुटि कोड लौटा सकता है

मैं आप लोगों के साथ बने रहने की कोशिश कर रहा हूं, लेकिन मुझे डर है कि ओपनएमपी के साथ मेरी पृष्ठभूमि की कमी मुझे थोड़ा पीछे है ... ऊपर की टिप्पणियों के आधार पर ऐसा लगता है कि KILL_PROCESS यहां एक व्यावहारिक समाधान हो सकता है? यदि ऐसा है, तो हम उस मुद्दे की प्राथमिकता को बढ़ा सकते हैं, हालांकि यह v2.4 रिलीज से पहले संबोधित करने के लिए चीजों की मेरी सूची में है।

• https://github.com/seccomp/libseccomp/milestone/2

@pcmoore - हां, मेरा मानना ​​है कि KILL_PROCESS इस बग का एक व्यवहार्य समाधान है। मैंने KILL_PROCESS कार्रवाई का उपयोग करके ऊपर @kloetzl के परीक्षण कार्यक्रम का परीक्षण किया और हैंग अब नहीं होता है।

मैंने इसे लागू कर दिया है, लेकिन वर्तमान में मैं अजगर ऑटोटेस्ट में कुछ झटके मार रहा हूं। मुझे अगले हफ्ते पैच आउट करना चाहिए।

@drakenclimber ऊह, पैच? मुझे पैच पसंद है :)

धन्यवाद दोस्तों।

मैं पुष्टि कर सकता हूं कि KILL_PROCESS इस मुद्दे को हल करता है: मैंने भी आर्क पर libseccomp का एक स्थानीय संस्करण हैक किया और परीक्षण कार्यक्रम इरादे के अनुसार विफल हो गया। हालाँकि, ठोस परीक्षण प्रदान करना और उन्हें विभिन्न कर्नेल पर चलाना एक बड़ी चुनौती हो सकती है।

@kloetzl की पुष्टि के लिए धन्यवाद।

हां, उचित परीक्षण लिखना कठिन हो सकता है, लेकिन यह महत्वपूर्ण है। कोड जितना ही महत्वपूर्ण है, यह IMHO का परीक्षण करता है।

मैं @drakenclimber से पीआर की प्रतीक्षा कर रहा हूं, कोड प्रकाशित होने के बाद हम चीजों पर कुछ और चर्चा कर सकते हैं।

मैं कुछ COVID-19 वसंत सफाई कर रहा हूं और मुझे लगता है कि हमने आपकी समस्या का समाधान कर लिया है, क्या यह सही है @kloetzl? मैं इस मुद्दे को बंद करने जा रहा हूं, लेकिन अगर मैं गलत हूं और आपको अभी भी समस्याएं दिखाई दे रही हैं तो कृपया हमें बताएं और हम इसे फिर से खोल देंगे!

मुझे याद दिलाने के लिए धन्यवाद, मैंने अपने अंत में थोड़ा सा परीक्षण किया।

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

आह, हाँ, मुझे यकीन नहीं है कि सिग्नल हैंडलर को libseccomp में ओवरराइट करने के बारे में हम बहुत कुछ कर सकते हैं, इसके बारे में खेद है।

हमें यह बताने के लिए धन्यवाद कि बाकी काम कर गया!