Libseccomp: RFE: seccomp_rule_add v2.4.0 . के बाद से बहुत धीमा हो गया है

हाय @varqox।

हां, syscall रिज़ॉल्वर फ़ंक्शन कुछ सुधार का उपयोग कर सकते हैं, वास्तव में यदि आप कोड को देखते हैं तो आपको निम्न की तरह कई टिप्पणियां दिखाई देंगी:

/* XXX - plenty of room for future improvement here */

यदि आप उस कोड को सुधारना चाहते हैं, तो हमें सहायता का उपयोग करना चाहिए!

जैसा कि @pcmoore ने उल्लेख किया है कि libseccomp का उपयोग करके एक seccomp फ़िल्टर के _creation_ को तेज़ करने के पर्याप्त अवसर हैं। ऊपर आपके शोध ने कई क्षेत्रों में से एक को रेखांकित किया है जो सुधार का उपयोग कर सकता है। यह मेरे उपयोगकर्ताओं के लिए चिंता का विषय नहीं है, इसलिए मैंने इस पर ध्यान केंद्रित नहीं किया है।

_runtime_ प्रदर्शन के संबंध में, मैं वर्तमान में बड़े फ़िल्टर के लिए एक बाइनरी ट्री का उपयोग करने पर काम कर रहा हूं जैसे आपने foo.c में प्रदान किया था। मेरे इन-हाउस ग्राहकों के साथ शुरुआती परिणाम आशाजनक दिख रहे हैं, लेकिन मुझे परिवर्तनों पर एक और नज़र रखना अच्छा लगेगा। पुल अनुरोध देखें https://github.com/seccomp/libseccomp/pull/152

ठीक है, मैं देखता हूं कि syscall समाधान में सुधार किया जा सकता है, लेकिन यह समस्या का मूल कारण नहीं है। जो है, जैसा कि मैं इसे देखता हूं, db_col_transaction_start() में एक स्नैपशॉट का निर्माण । वहाँ arch_filter_rule_add() कहा जाता है जो कि syscall को हल करने के कारण धीमा है, जिसे मूल नियम में हल किया गया है।

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

आंतरिक libseccomp डीबी संग्रह में सभी राज्यों के साथ, इसे डुप्लिकेट करना कोई छोटा काम नहीं है, मूल नियमों से संग्रह को पुन: उत्पन्न करना बहुत आसान है (कोड परिप्रेक्ष्य से)। मूल नियमों पर नज़र रखने से हम मौजूदा नियम (संभावित भविष्य की विशेषता) को "निकालने" की क्षमता भी प्रदान कर सकते हैं।

यह कहना नहीं है कि लेन-देन कोड में सुधार नहीं किया जा सकता है - यह निश्चित रूप से कर सकता है - लेकिन वर्तमान कोड वह तरीका है जो एक कारण के लिए है, मुख्य रूप से सादगी।

हम इस बदलाव के कारण उपयोगकर्ताओं से टाइमआउट देख रहे हैं। यह वास्तव में परिमाण के क्रम से चीजों को धीमा कर देता है।

एक और विचार, हम शायद इसे बदल सकते हैं ताकि हम केवल लेन-देन शुरू होने पर नियमों की नकल करें, पूरे पेड़ पर नहीं, और केवल एक असफल लेनदेन पर पेड़ को फिर से बनाएं। यह सही नहीं है, लेकिन इससे समय का एक अच्छा हिस्सा वापस मिल जाना चाहिए।

हमें कुछ करने की आवश्यकता है क्योंकि कंटेनरों और निष्पादन प्रक्रियाओं के लिए प्रारंभ समय में एक बड़ा प्रदर्शन प्रतिगमन देखा जा रहा है और लोगों को 2.3x पर पिन करने का कारण बन रहा है

मैं समस्या की _"विशाल"_ प्रकृति पर और टिप्पणी नहीं करने जा रहा हूं, उस परिप्रेक्ष्य को पहले ही कई बार बनाया जा चुका है और मैं इसे सापेक्ष और उपयोग-मामले दोनों पर निर्भर मानता हूं। हालांकि, मैं सभी को यह याद दिलाना चाहता था कि v2.4 से पहले libseccomp रिलीज एक संभावित भेद्यता के प्रति संवेदनशील है जिसे सार्वजनिक किया गया है (अंक #139)।

जो लोग इस मुद्दे के बारे में चिंतित हैं, उनके लिए वर्तमान में इसे v2.5 रिलीज़ के लिए चिह्नित किया गया है।

आपने एक रिफैक्टरिंग की है और इसमें मामूली रिलीज में "विशाल" प्रदर्शन प्रभाव पड़ता है और आप इसे उपयोग-मामले पर निर्भर कहकर इसे उड़ाकर सहायक नहीं हो रहे हैं। कृपया इसे गंभीरता से लें क्योंकि लोग 2.4 . के डिस्ट्रो अपडेट के रूप में नोटिस करना शुरू कर देंगे

@crosbymichael परिवर्तन केवल एक रिफैक्टरिंग नहीं था, समस्याओं को ठीक करना और कर्नेल में परिवर्तनों का समर्थन करना आवश्यक था (विशेष रूप से मल्टीप्लेक्स और डायरेक्ट कॉल सिस्को दोनों का समर्थन करने की आवश्यकता, जैसे 32-बिट x86 पर सॉकेट सिस्को)।

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

स्वयं को ध्यान दें और जो कोई भी इसे हल करने का प्रयास कर रहा है ...

मुझे हाल ही में याद दिलाया गया था कि हम लेन-देन के संबंध में जो करते हैं वह क्यों करते हैं (सब कुछ सामने कॉपी करें); हम ऐसा इसलिए करते हैं क्योंकि हमें बिना असफल हुए किसी लेनदेन को रोलबैक करने में सक्षम होना चाहिए। क्यों?
एक सामान्य seccomp_rule_add() ऑपरेशन को विफलता के मामले में भी फ़िल्टर को बरकरार रखने की आवश्यकता होती है; यदि हम एक सामान्य नियम जोड़ के हिस्से के रूप में एक बहु-भाग लेनदेन (उदाहरण के लिए x86/s390/s390x/आदि पर सॉकेट/आईपीसी syscalls) विफल हो जाते हैं, तो हमें बिना किसी असफलता के लेनदेन की शुरुआत में फ़िल्टर पर वापस जाने में सक्षम होना चाहिए ( स्मृति दबाव, आदि की परवाह किए बिना)।

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

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

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

• db_col_transaction_start() मौजूद होने पर छाया लेनदेन का उपयोग करने का प्रयास करना चाहिए, लेकिन यदि नहीं तो इसे वर्तमान व्यवहार में वापस आना चाहिए।
• db_col_transaction_abort() को वैसा ही व्यवहार करना चाहिए जैसा वह अभी करता है; इसका मतलब है कि एक असफल लेनदेन छाया लेनदेन को साफ़ कर देगा (इसे फ़िल्टर को पुनर्स्थापित करने के लिए पेड़ की आवश्यकता है), लेकिन अगला सफल लेनदेन छाया को पुनर्स्थापित करेगा। एक असफल लेनदेन इतना कम होना चाहिए कि यह एक प्रमुख मुद्दा नहीं होना चाहिए।
• हमें अन्य परिचालनों पर छाया लेनदेन को साफ़ करने की आवश्यकता हो सकती है, उदाहरण के लिए आर्क/एबीआई ऑप्स?, लेकिन यह कुछ ऐसा है जिसे हमें जांचना होगा। भले ही, छाया लेनदेन को साफ़ करना तुच्छ होना चाहिए।
• इसका न केवल नियम जोड़ने में तेजी लाने का लाभ है, बल्कि सामान्य रूप से लेनदेन में तेजी लाने का भी है। यह अब महत्वपूर्ण नहीं हो सकता है, लेकिन यह तब उपयोगी होगा जब हम उपयोगकर्ताओं के लिए लेनदेन की कार्यक्षमता का खुलासा करेंगे (यह आवश्यक होगा यदि हम कभी भी बीएसडी "प्रतिज्ञा" तंत्र की तरह करना चाहते हैं)।

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

• बेसलाइन टेस्ट ओवरहेड

# time for i in {0..20000}; do /bin/true; done
real    0m10.479s
user    0m7.641s
sys     0m3.924s

• वर्तमान मास्टर शाखा

# time for i in {0..20000}; do ./42-sim-adv_chains > /dev/null; done

real    0m16.303s
user    0m12.584s
sys     0m4.501s

• समझौता

time for i in {0..20000}; do ./42-sim-adv_chains > /dev/null; done

real    0m15.021s
user    0m11.540s
sys     0m4.387s

यदि हम परीक्षण ओवरहेड घटाते हैं तो हम इस "परीक्षण" पर प्रदर्शन में लगभग 20% की वृद्धि देख रहे हैं, लेकिन मुझे उम्मीद है कि जटिल फ़िल्टर सेट के लिए लाभ इससे बेहतर (बहुत बेहतर?) होगा।

@varqox और/या @crosbymichael एक बार जब मैं पैच को थोड़ा सा साफ कर देता हूं और पीआर बनाता हूं, तो क्या आप इसे अपने पर्यावरण में परीक्षण कर पाएंगे?

मेरा उदाहरण परीक्षण मामला पहले से ही यहाँ है:

नमस्ते,
मुद्दा ce3dda9 द्वारा v2.3.3 और v2.4.0 के बीच पेश किया गया था। निम्नलिखित उदाहरण पर विचार करें: foo.c.zip ।
यह बहुत बड़ी संख्या में नियम जोड़ता है। और उपर्युक्त प्रतिबद्धता के बाद लगभग 100 गुना धीमी गति से काम करता है।

foo.c v2.4.1 का उपयोग कर निष्पादन समय: 0.448
foo.c v2.3.3 का उपयोग कर निष्पादन समय: 0.077

लेकिन जैसे ही पीआर तैयार होता है, मैं इसे अपने परिवेश में परख सकता हूं।

हाय @varqox , हां मैंने देखा कि आपने मूल रिपोर्ट में एक परीक्षण केस शामिल किया है, लेकिन मुझे यह सुनने में अधिक दिलचस्पी है कि यह वास्तविक उपयोग में कैसा प्रदर्शन करता है। यदि आप पीआर #180 को आजमा सकते हैं और वापस रिपोर्ट कर सकते हैं तो मैं वास्तव में इसकी सराहना करता हूं - धन्यवाद!

हाय @pcmoore ,

इस पीआर को बनाने के लिए धन्यवाद।
मैंने आपके पीआर #180 का निर्माण और परीक्षण किया, परिणाम मेरे परीक्षण मामले के लिए आशाजनक है। मैं इस मुद्दे को देखता हूं क्योंकि ग्राहक डॉकर स्वास्थ्य-जांच का उपयोग करते हैं और libseccomp 2.4.x में प्रदर्शन समस्या से पीड़ित हैं।
मेरे परीक्षण मामले में, इस पीआर का प्रदर्शन libseccomp 2.3.3 के बराबर है। विवरण नीचे दिए गए हैं:

पर्यावरण

मैकबुक प्रो (15-इंच, मध्य 2015) पर उबंटू 19.04 वीएम (2 सीपीयू, 2 जी मेमोरी)
कर्नेल 5.0.0-32-जेनेरिक
डॉकर सीई 19.03.2

परीक्षण मामला:

20 कंटेनर तैयार करें:

for i in $(seq 1 20)
do
  docker run -d --name bb$i busybox sleep 3d
done

एक ही समय में सभी कंटेनरों पर docker exec फ़ायर करके परीक्षण चलाएँ

for i in $(seq 1 20)
do 
  /usr/bin/time -f "%E real" docker exec bb$i true & 
done

परिणाम

libseccomp 2.3.3

0:01.05 real
0:01.12 real
0:01.16 real
0:01.20 real
0:01.23 real
0:01.27 real
0:01.31 real
0:01.35 real
0:01.37 real
0:01.38 real
0:01.40 real
0:01.41 real
0:01.40 real
0:01.40 real
0:01.45 real
0:01.46 real
0:01.47 real
0:01.48 real
0:01.48 real
0:01.49 real

libseccomp 2.4.1

0:00.98 real
0:01.63 real
0:01.67 real
0:01.95 real
0:02.55 real
0:02.70 real
0:02.70 real
0:02.96 real
0:03.04 real
0:03.16 real
0:03.17 real
0:03.21 real
0:03.23 real
0:03.27 real
0:03.24 real
0:03.29 real
0:03.27 real
0:03.29 real
0:03.28 real
0:03.27 real

आपका पीआर बिल्ड

0:00.95 real
0:01.12 real
0:01.20 real
0:01.23 real
0:01.28 real
0:01.29 real
0:01.31 real
0:01.37 real
0:01.38 real
0:01.40 real
0:01.43 real
0:01.43 real
0:01.44 real
0:01.45 real
0:01.42 real
0:01.47 real
0:01.48 real
0:01.48 real
0:01.48 real
0:01.50 real

विविध नोट्स

• मैंने इस पीआर को बनाने से पहले 2.4.1 को AC_INIT में configure.ac में सेट किया था।
• यह कस्टम बिल्ड /usr/local/lib में स्थापित है, मैंने परीक्षण के दौरान कस्टम बिल्ड का उपयोग किया जा रहा है यह सुनिश्चित करने के लिए ldd /usr/bin/runc चलाकर इसे सत्यापित किया।
• मैंने कुछ बार परीक्षण चलाया, परिणामों में बहुत कम भिन्नताएं हैं। इसलिए मुझे विश्वास है कि वे आकस्मिक परिणाम नहीं हैं।

यह बहुत अच्छा है, @xinfengliu की मदद के लिए धन्यवाद!

हाय @pcmoore ,
इस जनसंपर्क के लिए धन्यवाद।
मेरे मामले में, यह libseccomp प्रदर्शन को v2.3.3.3 के साथ तुलनीय स्तर पर पुनर्स्थापित करता है।

परिणाम

फू.सी

g++ foo.c -lseccomp -o foo -O3
for ((i=0; i<10; ++i)); do time ./foo; done 

libseccomp 2.3.3

./foo  0.01s user 0.00s system 98% cpu 0.018 total
./foo  0.02s user 0.00s system 98% cpu 0.020 total
./foo  0.02s user 0.00s system 98% cpu 0.019 total
./foo  0.02s user 0.00s system 98% cpu 0.018 total
./foo  0.02s user 0.00s system 98% cpu 0.019 total
./foo  0.02s user 0.00s system 98% cpu 0.019 total
./foo  0.02s user 0.00s system 98% cpu 0.019 total
./foo  0.02s user 0.00s system 98% cpu 0.019 total
./foo  0.02s user 0.00s system 98% cpu 0.018 total
./foo  0.02s user 0.00s system 98% cpu 0.019 total

औसत: 0.0188 s

libseccomp 2.4.2

./foo  0.19s user 0.00s system 99% cpu 0.195 total
./foo  0.19s user 0.00s system 99% cpu 0.194 total
./foo  0.19s user 0.00s system 99% cpu 0.193 total
./foo  0.19s user 0.00s system 99% cpu 0.196 total
./foo  0.19s user 0.00s system 99% cpu 0.195 total
./foo  0.20s user 0.00s system 99% cpu 0.196 total
./foo  0.19s user 0.00s system 99% cpu 0.194 total
./foo  0.20s user 0.00s system 99% cpu 0.197 total
./foo  0.19s user 0.00s system 99% cpu 0.195 total
./foo  0.19s user 0.00s system 99% cpu 0.194 total

औसत: 0.1949 s

पीआर #180

./foo  0.01s user 0.01s system 98% cpu 0.012 total
./foo  0.01s user 0.00s system 97% cpu 0.013 total
./foo  0.01s user 0.00s system 96% cpu 0.013 total
./foo  0.01s user 0.01s system 97% cpu 0.014 total
./foo  0.01s user 0.00s system 97% cpu 0.012 total
./foo  0.01s user 0.00s system 98% cpu 0.013 total
./foo  0.01s user 0.00s system 98% cpu 0.012 total
./foo  0.01s user 0.00s system 98% cpu 0.013 total
./foo  0.01s user 0.00s system 97% cpu 0.013 total
./foo  0.01s user 0.00s system 97% cpu 0.011 total

औसत: 0.0126 s

ऐसा लगता है कि यह पीआर इस सिंथेटिक परीक्षण में v2.3.3 से अधिक गति देता है।

बिल्डिंग और लोडिंग (seccomp_init() से seccomp_load() तक) मेरे सैंडबॉक्स में फिल्टर और कुछ सैंडबॉक्स इनिशियलाइज़ेशन ओवरहेड

libseccomp 2.3.3

Measured: 0.0052 s
Measured: 0.0040 s
Measured: 0.0046 s
Measured: 0.0042 s
Measured: 0.0038 s
Measured: 0.0038 s
Measured: 0.0039 s
Measured: 0.0036 s
Measured: 0.0042 s
Measured: 0.0044 s
Measured: 0.0036 s
Measured: 0.0037 s
Measured: 0.0044 s
Measured: 0.0035 s
Measured: 0.0035 s
Measured: 0.0035 s
Measured: 0.0040 s
Measured: 0.0037 s
Measured: 0.0043 s
Measured: 0.0042 s
Measured: 0.0035 s
Measured: 0.0034 s
Measured: 0.0038 s
Measured: 0.0035 s
Measured: 0.0035 s
Measured: 0.0037 s
Measured: 0.0038 s

औसत: 0.0039 s

libseccomp 2.4.2

Measured: 0.0496 s
Measured: 0.0480 s
Measured: 0.0474 s
Measured: 0.0475 s
Measured: 0.0479 s
Measured: 0.0479 s
Measured: 0.0492 s
Measured: 0.0485 s
Measured: 0.0491 s
Measured: 0.0490 s
Measured: 0.0484 s
Measured: 0.0483 s
Measured: 0.0480 s
Measured: 0.0482 s
Measured: 0.0474 s
Measured: 0.0483 s
Measured: 0.0507 s
Measured: 0.0472 s
Measured: 0.0482 s
Measured: 0.0471 s
Measured: 0.0498 s
Measured: 0.0489 s
Measured: 0.0474 s
Measured: 0.0494 s
Measured: 0.0483 s
Measured: 0.0498 s
Measured: 0.0492 s

औसत: 0.0466 s

पीआर #180

Measured: 0.0058 s
Measured: 0.0059 s
Measured: 0.0054 s
Measured: 0.0046 s
Measured: 0.0059 s
Measured: 0.0048 s
Measured: 0.0045 s
Measured: 0.0051 s
Measured: 0.0052 s
Measured: 0.0053 s
Measured: 0.0048 s
Measured: 0.0048 s
Measured: 0.0045 s
Measured: 0.0044 s
Measured: 0.0044 s
Measured: 0.0059 s
Measured: 0.0044 s
Measured: 0.0046 s
Measured: 0.0046 s
Measured: 0.0044 s
Measured: 0.0044 s
Measured: 0.0062 s
Measured: 0.0047 s
Measured: 0.0044 s
Measured: 0.0044 s
Measured: 0.0044 s
Measured: 0.0044 s

औसत: 0.0049 s

हालांकि सिंथेटिक परीक्षण में पीआर v2.3.3 से बेहतर समय देता है, वास्तविक दुनिया में यह थोड़ा धीमा है (संभवतः अधिक जटिल नियमों और दो बड़े फिल्टर को मर्ज करने के लिए seccomp_merge() चलाने के कारण)। हालाँकि, यह अभी भी v2.4.2 की तुलना में लगभग दस गुना गति देता है।

@varqox प्रदर्शन को सत्यापित करने के लिए धन्यवाद! जैसे ही @drakenclimber टिप्पणियों के अंतिम दौर का जवाब देता है (और मैं उसके द्वारा लाए गए किसी भी शेष मुद्दे को ठीक करता हूं), हम इसे मर्ज कर देंगे।

आह, कोई बात नहीं, मैंने अभी देखा है कि @drakenclimber ने पीआर को स्वीकृत के रूप में चिह्नित किया है। मैं आगे बढ़ने जा रहा हूं और अब इसे मर्ज कर दूंगा।

मैंने अभी पीआर # 180 को मर्ज किया है, इसलिए मुझे लगता है कि हम इसे बंद के रूप में चिह्नित कर सकते हैं, अगर किसी को कोई शेष प्रदर्शन समस्या दिखाई देती है तो टिप्पणी करने और/या फिर से खोलने के लिए स्वतंत्र महसूस करें। आपके धैर्य और मदद के लिए सभी को धन्यवाद!

@pcmoore क्या आप उन परिवर्तनों के साथ शीघ्र ही रिलीज़ करने की योजना बना रहे हैं?

यह वर्तमान में libseccomp v2.5 रिलीज़ माइलस्टोन का हिस्सा है, आप नीचे दिए गए लिंक का उपयोग करके v2.5 रिलीज़ की दिशा में हमारी प्रगति को ट्रैक कर सकते हैं:

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