Libseccomp: RFE: अज्ञात syscalls को अलग करें

को निर्मित 16 अग॰ 2020 · 18टिप्पणियाँ · स्रोत: seccomp/libseccomp

सिस्टमड-डेवेल पर एक चर्चा ( जून और अगस्त में ) द्वारा ट्रिगर किया गया ..

systemd-nspawn गैर-श्वेतसूचीबद्ध syscalls के लिए EPERM वापस करना चुनता है। हालांकि, यह openat2 जैसे मामलों में समस्या का कारण बनता है, जहां libc ENOSYS जांच करता है और एक अलग कार्यान्वयन पर वापस आ जाता है।

यह मुझे लगता है कि एक 'ज्यादातर सही' समाधान यह जांचने के लिए हो सकता है कि क्या सिस्कल संख्या परिभाषित सिस्को की सीमा के भीतर आती है जो उस समय मौजूद थी जब seccomp बनाया गया था। मुझे यकीन है कि कोने के मामले हैं (मुझे पता है कि कुछ आर्क अजीब चीजें करते हैं), लेकिन अगर syscalls.csv आदि को पार्स करने वाले टूल अधिकतम ज्ञात सिस्कल संख्या के लिए एक साधारण #define उत्पन्न कर सकते हैं जो हो सकता है उपयोगी?

enhancement prioritmedium

स्रोत

srd424

सबसे उपयोगी टिप्पणी

ऊपर की चर्चा के आधार पर, ऐसा लगता है कि यहां के अधिकांश (सभी?) लोग मानते हैं कि अंक #11 इस मुद्दे को हल करने का सही तरीका है; क्या किसी को भविष्य की चर्चा को मूल मुद्दे (#11) पर ले जाने के पक्ष में इस मुद्दे को बंद करने में कोई समस्या है?

pcmoore 2 दिस॰ 2020

👍2

सभी 18 टिप्पणियाँ

हाय @ srd424। मैं यह सुनिश्चित करना चाहता हूं कि मैं समझता हूं कि आप इस मुद्दे में क्या मांग रहे हैं ... /एबीआई, हाँ?

यदि ऐसा है, तो मेरा मानना है कि आपको अपनी इच्छित जानकारी प्राप्त करने के लिए seccomp_syscall_resolve_name(...) का उपयोग करने में सक्षम होना चाहिए। यदि वापसी मूल्य __NR_SCMP_ERROR तो syscall libseccomp के लिए अज्ञात है, यदि यह सकारात्मक है तो syscall देशी आर्क/ABI में मौजूद है, और यदि यह ऋणात्मक है तो syscall देशी आर्क पर मौजूद नहीं है/ एबीआई। क्या ये तुम्हारे लिए कारगर है?

pcmoore 16 अग॰ 2020

यह फिल्टर बना सकता है .. लंबा-चौड़ा!

मैं जो करने की उम्मीद कर रहा था, वह यह है कि एक फिल्टर नियम की तुलना सिस्कल संख्या की उच्चतम ज्ञात संख्या से करें, और यदि अधिक हो, तो ENOSYS लौटाएं, अन्यथा EPERM लौटाएं (यह मानते हुए कि श्वेतसूचीबद्ध सिस्को को संभाला गया है) पहले के नियम से।)

हालांकि seccomp_rule_add के विवरण को देखते हुए, मुझे यकीन नहीं है कि यह काम करने जा रहा है .. syscall नंबर का विशेष रूप से इलाज किया जाता है। ऐसा करने के लिए संभवतः एक कच्चा बीपीएफ फ़िल्टर बनाया जा सकता है, लेकिन इसका मतलब है कि libseccomp में कुछ और आक्रामक परिवर्तन - शायद मेरे वेतन ग्रेड से ऊपर!

srd424 16 अग॰ 2020

यह libseccomp में जोड़ने के लिए उचित कार्यक्षमता हो भी सकता है और नहीं भी हो सकता है क्योंकि मुझे लगता है कि मूल समस्या पुस्तकालय के एकाधिक उपयोगकर्ताओं के लिए हो सकती है। ऐसा लगता है कि यह (बस?) थोड़ा अधिक परिष्कृत डिफ़ॉल्ट क्रिया उत्पन्न करने का प्रश्न होगा ..

srd424 16 अग॰ 2020

यह फिल्टर बना सकता है .. लंबा-चौड़ा!

मुझे पूरा यकीन नहीं है कि आपका यहाँ क्या मतलब है ...? seccomp_syscall_resolve_name(...) कॉल वास्तव में फ़िल्टर को प्रभावित नहीं करती है, यह केवल syscall रिज़ॉल्यूशन करने के लिए आंतरिक libseccomp syscall db से पूछताछ करती है। आप इसे एक बार, एक हजार बार, या कभी नहीं कॉल कर सकते हैं और आपका फ़िल्टर बिल्कुल वैसा ही होगा :)

मैं जो करने की उम्मीद कर रहा था, वह यह है कि एक फिल्टर नियम की तुलना syscall संख्या की उच्चतम ज्ञात से करें, और यदि अधिक हो, तो ENOSYS लौटाएं, अन्यथा EPERM लौटाएं (यह मानते हुए कि श्वेतसूची वाले सिस्को को पहले के नियम द्वारा नियंत्रित किया गया है।)

ठीक है, मुझे लगता है कि मुझे समझ में आने लगा है कि आप अभी क्या माँग रहे हैं। यदि आप syscall libseccomp के लिए अनजान है, तो आप एक निश्चित कार्रवाई करने के लिए फ़िल्टर स्वयं चाहते हैं, एप्लिकेशन कोड नहीं (उपरोक्त उदाहरण में ENOSYS लौटाएं)? क्या यह मूल रूप से है, या क्या मुझे फिर से कुछ याद आ रहा है?

pcmoore 17 अग॰ 2020

ऊपर उल्लिखित दूसरे सूत्र में इस टिप्पणी ने मुझे मुस्कुरा दिया: +1:

मैंने libseccomp में ENOSYS हैंडलिंग के बारे में एक चर्चा खोलने की कोशिश की है
https://github.com/seccomp/libseccomp/issues/286 , लेकिन मैं शायद नहीं हूं
बहुत सुसंगत होना ..

आपके द्वारा उल्लिखित धागों को पढ़ने के बाद, मुझे लगता है कि मैं उसी पृष्ठ पर हूँ।

अगर कोई (libseccomp, nspawn, whoever) ENOSYS वापस कर सकता है, तो glibc नए syscall, जैसे openat2 से पुराने syscall, जैसे openat वापस आने का प्रयास करेगा। EPERM को glibc पर वापस करने से glibc को लगता है कि कॉल की अनुमति नहीं थी, और glibc हार मान लेगा। क्या यह इस मुद्दे में प्रारंभिक टिप्पणी का उचित पुनर्लेखन है?

मुझे लगता है कि अनुरोध उचित है। मुझे कुछ और सोचने की जरूरत है अगर libseccomp इन जरूरतों को पूरा कर सकता है, लेकिन मुझे इस समय कोई आपत्ति नहीं है। यहां अंतिम-उपयोगकर्ता अनुभव को बेहतर बनाने के निश्चित रूप से अवसर हैं।

आरएफई के लिए धन्यवाद।

drakenclimber 17 अग॰ 2020

👍2

अगर कोई (libseccomp, nspawn, whoever) ENOSYS वापस कर सकता है, तो glibc नए syscall, जैसे openat2 से पुराने syscall, जैसे openat वापस आने का प्रयास करेगा। EPERM को glibc पर वापस करने से glibc को लगता है कि कॉल की अनुमति नहीं थी, और glibc हार मान लेगा। क्या यह इस मुद्दे में प्रारंभिक टिप्पणी का उचित पुनर्लेखन है?

हाँ, यह सही लगता है। सिस्टमड लोगों की राय यह है कि EPERM ज्यादातर समय अस्वीकृत syscalls के लिए उचित है, संभवतः क्योंकि यह अंतिम उपयोगकर्ता/व्यवस्थापक को "अनुमति नहीं" बताता है। इसलिए "नए" और "पुराने" सिस्को के बीच अंतर करने का विचार और किसी भी अपरिचित चीज़ के लिए ENOSYS करना। मुझे लगता है कि हम प्रदर्शन कारणों से बीपीएफ में प्रत्येक सिस्कल की गणना और परीक्षण नहीं करना चाहते हैं, इसलिए ज्ञात सिस्कल नंबर प्रति-आर्क के लिए उच्च पानी के निशान को ट्रैक करना एक "सर्वश्रेष्ठ प्रयास" तरीका प्रतीत होता है।

यह जानना दिलचस्प होगा कि docker, podman, lxc आदि अपने seccomp फ़िल्टरिंग के साथ क्या करते हैं, यह देखने के लिए कि क्या उन्हें लाभ होगा। इस बीच मैंने nspawn के लिए एक पैच तैयार किया है जो seccomp घटनाओं को लॉग करने की अनुमति देगा, जिससे डिबगिंग थोड़ा आसान हो जाएगा।

srd424 17 अग॰ 2020

👍1

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

मैं @drakenclimber से सहमत

एक बहुत ही बुनियादी स्तर पर, यह आरएफई #11 के समान है, और अंत में इसे लागू करने का सबसे आसान तरीका हो सकता है जो अनुप्रयोगों के लिए भयानक नहीं है: एक एप्लिकेशन अधिकतम समर्थित कर्नेल एपीआई संस्करण निर्दिष्ट कर सकता है, उदाहरण के लिए v5.8 (जाहिर तौर पर टोकनयुक्त), साथ ही आगे की किसी भी चीज़ के लिए दी गई कार्रवाई और फिर libseccomp बाकी को संभालता है। क्या यह आप लोगों के लिए काम करेगा @ srd424?

pcmoore 18 अग॰ 2020

नमस्ते, इस पर https://github.com/systemd/systemd/pull/16739 में भी चर्चा की गई थी

एक एप्लिकेशन अधिकतम समर्थित कर्नेल एपीआई संस्करण निर्दिष्ट कर सकता है, उदाहरण के लिए v5.8 (स्पष्ट रूप से टोकनयुक्त), साथ ही साथ किसी भी चीज़ के लिए दी गई कार्रवाई और फिर libseccomp बाकी को संभालता है।

यह बहुत अच्छा काम करेगा। systemd/systemd-nspawn में हम किसी भी स्पष्ट रूप से अनुमति-सूचीबद्ध और अस्वीकार-सूचीबद्ध syscalls, "समर्थित कर्नेल API संस्करण" में किसी अन्य के लिए EPERM और किसी भी नए के लिए ENOSYS के लिए कस्टम त्रुटियों को वापस करना चाहते हैं।

मुझे लगता है कि कार्यान्वयन बहुत जटिल नहीं होगा। उदाहरण के लिए amd64 के लिए, "ज्ञात" syscalls को n <= 181 || 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439 रूप में व्यक्त किया जा सकता है। और इस तरह के भाव आसानी से syscall तालिकाओं से प्रोग्रामेटिक रूप से उत्पन्न किए जा सकते हैं।

keszybz 19 अग॰ 2020

94 भी संबंधित हो सकता है।

topimiettinen 19 अग॰ 2020

मैं आज सुबह कम कैफीनयुक्त हूं, लेकिन क्या ENOSYS को संभालने से हमें संभावित प्रदर्शन जीत के लिए बड़ी अनुमति देने वालों को छोटे इनकार करने वालों में बदलने की संभावना मिलती है?

srd424 19 अग॰ 2020

मुझे लगता है कि कार्यान्वयन बहुत जटिल नहीं होगा। उदाहरण के लिए amd64 के लिए, "ज्ञात" syscalls को n <= 181 || . के रूप में व्यक्त किया जा सकता है 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439। और इस तरह के भाव आसानी से syscall तालिकाओं से प्रोग्रामेटिक रूप से उत्पन्न किए जा सकते हैं।

जैसा कि आप संकेत देते हैं, वास्तविक बीपीएफ आर्क/एबीआई और कर्नेल संस्करण दोनों विशिष्ट होने जा रहा है। बीपीएफ के ऊपर x86_64 उदाहरण में बहुत बुरा नहीं होगा, लेकिन हम अन्य मेहराब/संस्करणों के लिए भाग्यशाली नहीं होंगे। भले ही, यह अब दो मुद्दे हैं जो प्रभावी रूप से एक ही चीज़ का अनुरोध कर रहे हैं, इसलिए मुझे लगता है कि यह कुछ ऐसा है जिसे हम करना चाहेंगे ... मैं अभी ऊपर और नीचे कूदना शुरू नहीं करने जा रहा हूं कि यह अभी कितना आसान होने वाला है; )

94 भी संबंधित हो सकता है।

हां की तरह, नहीं की तरह। इसमें श्रेणियां शामिल हैं, लेकिन #94 कॉलर निर्दिष्ट तर्क श्रेणियों के बारे में है (जो अभी भी कुछ ऐसा है जो मुझे लगता है कि हम करना चाहते हैं, पीआर अभी खराब समय पर आया है और मुझे लगता है कि एपीआई को कुछ ट्विकिंग की जरूरत है) जबकि हम जो बात कर रहे हैं वह है परोक्ष रूप से निर्मित syscall पर्वतमाला जो पुस्तकालय द्वारा ही उत्पन्न की जाती हैं।

मैं आज सुबह कम कैफीनयुक्त हूं, लेकिन क्या ENOSYS को संभालने से हमें संभावित प्रदर्शन जीत के लिए बड़ी अनुमति देने वालों को छोटे इनकार करने वालों में बदलने की संभावना मिलती है?

एक एप्लिकेशन के नजरिए से, जैसे सिस्टमड, यदि आप "नए" सिस्को को ब्लॉक करने की कोशिश कर रहे हैं तो हाँ ... मान लीजिए कि हम एक ही चीज़ के बारे में बात कर रहे हैं :)

pcmoore 19 अग॰ 2020

अधिक विशिष्ट होने के लिए .. फिलहाल किसी को भी _सुरक्षित रूप से कुछ syscalls को प्रभावी ढंग से ब्लॉक करने का प्रयास करने के लिए अनुमति देना होगा, क्योंकि आप सुनिश्चित नहीं हो सकते कि एक नया कर्नेल क्या जोड़ सकता है। यदि हम libseccomp को अज्ञात syscalls को स्वचालित रूप से ब्लॉक करने का अनुरोध कर सकते हैं, तो इसका मतलब है कि हम सुरक्षित रूप से एक छोटे से इनकार सूची में स्विच कर सकते हैं?

srd424 19 अग॰ 2020

👍1

अधिक विशिष्ट होने के लिए .. फिलहाल किसी को भी _सुरक्षित रूप से कुछ syscalls को प्रभावी ढंग से ब्लॉक करने का प्रयास करने के लिए अनुमति देना होगा, क्योंकि आप सुनिश्चित नहीं हो सकते कि एक नया कर्नेल क्या जोड़ सकता है। यदि हम libseccomp को अज्ञात syscalls को स्वचालित रूप से ब्लॉक करने का अनुरोध कर सकते हैं, तो इसका मतलब है कि हम सुरक्षित रूप से एक छोटे से इनकार सूची में स्विच कर सकते हैं?

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

इतनी बड़ी सूची का प्रदर्शन प्रभाव निषेधात्मक हो सकता है। ध्यान दें कि इसे हमने v2.5 में जोड़े गए बाइनरी ट्री फीचर का उपयोग करके कुछ हद तक कम किया जा सकता है।

drakenclimber 19 अग॰ 2020

अधिक विशिष्ट होने के लिए .. फिलहाल किसी को भी _सुरक्षित रूप से कुछ syscalls को प्रभावी ढंग से ब्लॉक करने का प्रयास करने के लिए अनुमति देना होगा, क्योंकि आप सुनिश्चित नहीं हो सकते कि एक नया कर्नेल क्या जोड़ सकता है। यदि हम libseccomp को अज्ञात syscalls को स्वचालित रूप से ब्लॉक करने का अनुरोध कर सकते हैं, तो इसका मतलब है कि हम सुरक्षित रूप से एक छोटे से इनकार सूची में स्विच कर सकते हैं?

मैं नहीं देखता कि यह कैसे काम कर सकता है। libseccomp के लिए अज्ञात और इनकार करने वाले लेखक के लिए अज्ञात का अर्थ आमतौर पर अलग-अलग चीजों से होगा। जिसका अर्थ है कि वैचारिक मुद्दा दूर नहीं होगा, भले ही libseccomp के पास समर्थित सिस्टम कॉल की एक स्पष्ट तस्वीर आंतरिक रूप से हो।

fweimer 21 अग॰ 2020

अच्छा बिंदु - मुझे लगता है कि काम करने के लिए हमें कर्नेल संस्करण द्वारा टैग किए गए अच्छी तरह से परिभाषित सेट की आवश्यकता होगी, जिस पर कुछ चर्चा की जा रही है।

srd424 21 अग॰ 2020

मुझे लगता है कि कार्यान्वयन बहुत जटिल नहीं होगा। उदाहरण के लिए amd64 के लिए, "ज्ञात" syscalls को n <= 181 || . के रूप में व्यक्त किया जा सकता है 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439। और इस तरह के भाव आसानी से syscall तालिकाओं से प्रोग्रामेटिक रूप से उत्पन्न किए जा सकते हैं।
जैसा कि आप संकेत देते हैं, वास्तविक बीपीएफ आर्क/एबीआई और कर्नेल संस्करण दोनों विशिष्ट होने जा रहा है। बीपीएफ के ऊपर x86_64 उदाहरण में बहुत बुरा नहीं होगा, लेकिन हम अन्य मेहराब/संस्करणों के लिए भाग्यशाली नहीं होंगे। भले ही, यह अब दो मुद्दे हैं जो प्रभावी रूप से एक ही चीज़ का अनुरोध कर रहे हैं, इसलिए मुझे लगता है कि यह कुछ ऐसा है जिसे हम करना चाहेंगे ... मैं अभी ऊपर और नीचे कूदना शुरू नहीं करने जा रहा हूं कि यह अभी कितना आसान होने वाला है; )

टेबल काफी निरंतर हैं:

>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-x86_64').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([ 1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  5,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1, 90,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-alpha').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([ 1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  3,  1,  2,  1,  1,
        1,  1,  1,  2,  1,  1,  1,  3, 12,  3,  3,  1, 11,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        2,  1,  1,  1,  1,  1,  1,  5,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1, 39,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  3,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        2,  1,  1,  1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-arm').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 2, 1, 1, 3, 1, 1, 2, 1, 2, 3, 4,
       1, 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 2, 1, 1, 1, 2, 1, 2, 3, 1, 1,
       1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 2, 2, 1, 1, 1, 3,
       1, 1, 1, 1, 1, 1, 2, 1, 3, 1, 1, 1, 1, 1, 3, 3, 1, 1, 2, 1, 1, 1,
       1, 2, 1, 1, 2, 1, 2, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-riscv64').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([  1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   2,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,  16,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1, 130,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1])

मैंने https://github.com/systemd/systemd/pull/16819 में systemd-nspawn के लिए "ज्ञात" syscalls का एक फ़िल्टर लागू किया https://github.com/systemd/systemd/pull/16819/commits/158e30ffd9355a7640a7276276eb9219b6c87914 में कुछ libseccomp-जनित प्रोग्रामों का डंप है। वे डंप लंबे हैं, इसलिए मैं उन्हें यहां नहीं दोहराऊंगा, लेकिन SCMP_FLTATR_CTL_OPTIMIZE कार्यक्रम को और अधिक कुशल बनाता है, लेकिन यह भी लंबा है। रेंज तुलनाओं का उपयोग करके चीजों को ~50 गुना छोटा बनाया जा सकता है।

keszybz 22 अग॰ 2020

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

cyphar 27 नव॰ 2020

❤1

pcmoore 2 दिस॰ 2020

👍2

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Libseccomp: RFE: अज्ञात syscalls को अलग करें

सबसे उपयोगी टिप्पणी

सभी 18 टिप्पणियाँ

94 भी संबंधित हो सकता है।

94 भी संबंधित हो सकता है।

संबंधित मुद्दों