Libseccomp: RFE: التمييز بين عمليات السحاب غير المعروفة

تم إنشاؤها على ١٦ أغسطس ٢٠٢٠  ·  18تعليقات  ·  مصدر: seccomp/libseccomp

الناجمة عن مناقشة (في يونيو و أغسطس ) على سيستم دي-جمعة ..

اختار systemd-nspawn إرجاع EPERM لمكالمات syscalls غير المدرجة في القائمة البيضاء. ومع ذلك ، يتسبب هذا في حدوث مشكلات في حالات مثل openat2 ، حيث يتحقق libc من ENOSYS ويعود إلى تطبيق مختلف.

يبدو لي أن الحل "الصحيح في الغالب" هو التحقق مما إذا كان رقم syscall يقع ضمن نطاق عمليات syscalls المحددة التي كانت موجودة في الوقت الذي تم فيه إنشاء seccomp. أنا متأكد من وجود حالات ركنية (أعرف أن بعض الأقواس تقوم بأشياء غريبة) ، ولكن إذا كانت الأدوات التي تحلل syscalls.csv وما إلى ذلك يمكن أن تولد #define بسيطًا لأقصى عدد معروف من أرقام الاتصال التي قد تكون مفيد؟

enhancement prioritmedium
مصدر
picture srd424

التعليق الأكثر فائدة

بناءً على المناقشة أعلاه ، يبدو أن معظم (كل؟) الأشخاص هنا يعتقدون أن المشكلة رقم 11 هي الطريقة الصحيحة لحل هذه المشكلة ؛ هل لدى أي شخص مشكلة في إغلاق هذا الموضوع لصالح نقل المناقشة المستقبلية إلى الإصدار الأصلي (# 11)؟

picture pcmoore في ٢ ديسمبر ٢٠٢٠
👍2

ال 18 كومينتر

مرحبًا @ srd424. أريد أن أتأكد من فهمي لما تطلبه في هذه المشكلة ... يبدو لي أنك ترغب أساسًا في معرفة ما إذا كان libseccomp "يعرف" بمكالمة نظام معينة ، بغض النظر عما إذا كان قد تم تنفيذ هذا النظام على هذا القوس / ABI ، نعم؟

إذا كان الأمر كذلك ، أعتقد أنه يجب أن تكون قادرًا على استخدام seccomp_syscall_resolve_name(...) للحصول على المعلومات التي تريدها. إذا كانت قيمة الإرجاع هي __NR_SCMP_ERROR فإن syscall غير معروف لـ libseccomp ، وإذا كانت موجبة ، فإن syscall موجود في القوس الأصلي / ABI ، وإذا كانت سلبية ، فإن syscall غير موجود في القوس الأصلي / ABI. هل هذا مناسب لك؟

pcmoore picture pcmoore في ١٦ أغسطس ٢٠٢٠

قد تجعل المرشحات .. طويلة الرياح!

ما كنت آمل أن أفعله هو الحصول على قاعدة تصفية تقارن رقم syscall بأعلى رقم معروف ، وإذا كان أكبر ، قم بإرجاع ENOSYS ، وإلا قم بإرجاع EPERM (بافتراض أنه تم التعامل مع مكالمات syscall المدرجة في القائمة البيضاء بقاعدة سابقة.)

لكن بالنظر إلى تفاصيل seccomp_rule_add ، لست متأكدًا من أن ذلك سيعمل .. يتم التعامل مع رقم syscall بشكل خاص. من المفترض أن يتم إنشاء مرشح bpf خام للقيام بذلك ، ولكن هذا سيعني بعض التغييرات الأكثر توغلًا في libseccomp - ربما أعلى من درجة راتبي!

srd424 picture srd424 في ١٦ أغسطس ٢٠٢٠

قد تكون إضافة وظيفة إلى libseccomp أو لا تكون كذلك ، حيث أعتقد أن المشكلة الأصلية قد تحدث للعديد من مستخدمي المكتبة. يبدو أنه سيكون (فقط؟) مسألة إنشاء إجراء افتراضي أكثر تعقيدًا بعض الشيء ..

srd424 picture srd424 في ١٦ أغسطس ٢٠٢٠

قد تجعل المرشحات .. طويلة الرياح!

لست متأكدًا تمامًا مما تعنيه هنا ...؟ استدعاء seccomp_syscall_resolve_name(...) لا يؤثر فعليًا على عامل التصفية ، بل يقوم فقط بالاستعلام عن libseccomp syscall db الداخلي لتنفيذ قرار syscall. يمكنك تسميتها مرة واحدة ، أو ألف مرة ، أو لا تسميها مطلقًا وسيكون الفلتر الخاص بك هو نفسه تمامًا :)

ما كنت أتمنى القيام به هو الحصول على قاعدة تصفية تقارن رقم syscall بأعلى رقم معروف ، وإذا كان أكبر ، قم بإرجاع ENOSYS ، وإلا قم بإرجاع EPERM (بافتراض أنه تمت معالجة طلبات syscall المدرجة في القائمة البيضاء بواسطة قاعدة سابقة.)

حسنًا ، أعتقد أنني بدأت أفهم ما تطلبه الآن. هل تريد أن يتخذ عامل التصفية نفسه ، وليس رمز التطبيق ، إجراءً معينًا (إرجاع ENOSYS في المثال أعلاه) إذا كان syscall غير معروف لـ libseccomp؟ هل هذا في الأساس ، أم أنني أفتقد شيئًا مرة أخرى؟

pcmoore picture pcmoore في ١٧ أغسطس ٢٠٢٠

هذا التعليق في الموضوع الثاني المذكور أعلاه جعلني أبتسم: +1:

لقد حاولت فتح مناقشة حول معالجة ENOSYS في libseccomp في
https://github.com/seccomp/libseccomp/issues/286 ، لكنني على الأرجح لست كذلك
كونها متماسكة جدا ..

بعد قراءة المواضيع التي ذكرتها ، أعتقد أنني على نفس الصفحة.

إذا كان بإمكان شخص ما (libseccomp ، nspawn ، أيا كان) إرجاع ENOSYS ، فسيحاول glibc الرجوع من نظام syscall الأحدث ، على سبيل المثال openat2 ، إلى نظام syscall الأقدم ، على سبيل المثال openat . إرجاع EPERM إلى glibc يجعل glibc يعتقد أن المكالمة غير مسموح بها ، وسوف يستسلم glibc. هل هذه إعادة صياغة عادلة للتعليق الأولي في هذه المسألة؟

أعتقد أن الطلب معقول. أحتاج إلى التفكير أكثر إذا كان libseccomp يمكنه تلبية هذه الاحتياجات ، لكن ليس لدي أي اعتراضات في هذه المرحلة. هناك بالتأكيد فرص لتحسين تجربة المستخدم النهائي هنا.

شكرا على RFE.

drakenclimber picture drakenclimber في ١٧ أغسطس ٢٠٢٠
👍2

إذا كان بإمكان شخص ما (libseccomp ، nspawn ، أيا كان) إرجاع ENOSYS ، فسيحاول glibc الرجوع من نظام syscall الأحدث ، على سبيل المثال openat2 ، إلى نظام syscall الأقدم ، على سبيل المثال openat . إرجاع EPERM إلى glibc يجعل glibc يعتقد أن المكالمة غير مسموح بها ، وسوف يستسلم glibc. هل هذه إعادة صياغة عادلة للتعليق الأولي في هذه المسألة؟

نعم ، هذا يبدو صحيحًا. رأي مستخدمي systemd هو أن EPERM معقول في معظم الأحيان بالنسبة إلى عمليات syscalls التي تم رفضها ، ويفترض أنها تنقل "غير مسموح به" إلى المستخدم النهائي / المشرف. ومن هنا جاءت فكرة التمييز بين محاولات النظام "الجديدة" و "القديمة" وعمل ENOSYS لأي شيء غير معروف. أفترض أننا لا نريد تعداد واختبار كل مكالمة نظام في BPF لأسباب تتعلق بالأداء ، لذا فإن تتبع علامة مائية عالية لأرقام مكالمات النظام المعروفة لكل قوس بدا وكأنه طريقة "أفضل مجهود" للذهاب.

سيكون من المثير للاهتمام معرفة ما يفعله عامل التحميل ، والبودمان ، و lxc وما إلى ذلك مع تصفية seccomp الخاصة بهم ، لمعرفة ما إذا كانوا سيستفيدون. في هذه الأثناء ، لدي PR رقعة لـ nspawn تسمح بتسجيل أحداث seccomp ، مما يجعل تصحيح الأخطاء أسهل قليلاً.

srd424 picture srd424 في ١٧ أغسطس ٢٠٢٠
👍1

أعتقد أن الطلب معقول. أحتاج إلى التفكير أكثر إذا كان libseccomp يمكنه تلبية هذه الاحتياجات ، لكن ليس لدي أي اعتراضات في هذه المرحلة. هناك بالتأكيد فرص لتحسين تجربة المستخدم النهائي هنا.

شكرا على RFE.

أتفق مع drakenclimber ، يبدو هذا الطلب معقولًا ، وأعتقد أنني بحاجة إلى مزيد من الوقت للتفكير في الحلول الممكنة :)

على مستوى أساسي جدًا ، هذا مشابه لـ RFE # 11 ، وفي النهاية قد يكون هذا هو أسهل طريقة لتنفيذ ذلك بطريقة ليست رهيبة للتطبيقات: يمكن للتطبيق تحديد أقصى إصدار مدعوم من kernel API ، على سبيل المثال v5.8 (مرمز بشكل واضح) ، بالإضافة إلى إجراء معين لأي شيء بعد ذلك ، ثم يقوم libseccomp بمعالجة الباقي. هل سيعمل هذا من أجلكم يا رفاق @ srd424؟

pcmoore picture pcmoore في ١٨ أغسطس ٢٠٢٠

مرحبًا ، تمت مناقشة هذا أيضًا في https://github.com/systemd/systemd/pull/16739.

يمكن للتطبيق تحديد الحد الأقصى من إصدار واجهة برمجة تطبيقات kernel المدعوم ، على سبيل المثال v5.8 (مرمز بشكل واضح) ، بالإضافة إلى إجراء معين لأي شيء بعد ذلك ، ثم يقوم libseccomp بمعالجة الباقي.

هذا سيعمل بشكل رائع. في systemd / systemd-nspawn ، نرغب في إرجاع أخطاء مخصصة لأي مكالمات syscalls مُدرجة ومُرفضة بشكل صريح ، و EPERM لأي مكالمات أخرى في "إصدار kernel API المدعوم" ، و ENOSYS لأي مكالمات جديدة.

أعتقد أن التنفيذ لن يكون معقدًا للغاية. على سبيل المثال بالنسبة لـ amd64 ، يمكن التعبير عن مكالمات syscalls "المعروفة" على أنها n <= 181 || 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439 . ويمكن إنشاء مثل هذه التعبيرات بسهولة برمجيًا من جداول syscall.

keszybz picture keszybz في ١٩ أغسطس ٢٠٢٠

94 يمكن أن تكون مرتبطة أيضا.

topimiettinen picture topimiettinen في ١٩ أغسطس ٢٠٢٠

أنا أعاني من نقص في الكافيين هذا الصباح ، ولكن هل يمنحنا التعامل مع ENOSYS ثم إمكانية تحويل قوائم السماح الكبيرة إلى denylists صغيرة لتحقيق فوز محتمل في الأداء أيضًا؟

srd424 picture srd424 في ١٩ أغسطس ٢٠٢٠

أعتقد أن التنفيذ لن يكون معقدًا للغاية. على سبيل المثال بالنسبة لـ amd64 ، يمكن التعبير عن عمليات syscalls "المعروفة" بالشكل n <= 181 || 186 <= ن <= 235 || 237 <= ن <= 334 || 424 <= n <= 439. ويمكن إنشاء مثل هذه التعبيرات بسهولة برمجيًا من جداول syscall.

كما تشير إلى ذلك ، فإن BPF الفعلي سيكون خاصًا بإصدار arch / ABI و kernel. في مثال x86_64 أعلاه ، لن يكون BPF سيئًا للغاية ، لكننا لسنا محظوظين بالنسبة للأقواس / الإصدارات الأخرى. بغض النظر ، هذه الآن مشكلتان تتطلبان نفس الشيء بشكل فعال لذلك أعتقد أنه شيء نريد القيام به ... لن أبدأ في القفز لأعلى ولأسفل حول مدى سهولة الأمر حتى الآن ؛ )

94 يمكن أن تكون مرتبطة أيضا.

نوعا ما نعم ، نوعا ما لا. إنه يتضمن نطاقات ، لكن # 94 يتعلق بنطاقات وسيطة محددة للمتصل (وهو ما أعتقد أننا نريد القيام به ، جاء PR للتو في وقت سيئ وأعتقد أن واجهة برمجة التطبيقات تحتاج إلى بعض التغيير والتبديل) في حين أن ما نتحدث عنه هو تم إنشاء نطاقات syscall ضمنيًا والتي تم إنشاؤها بواسطة المكتبة نفسها.

أنا أعاني من نقص في الكافيين هذا الصباح ، ولكن هل يمنحنا التعامل مع ENOSYS ثم إمكانية تحويل قوائم السماح الكبيرة إلى denylists صغيرة لتحقيق فوز محتمل في الأداء أيضًا؟

من منظور تطبيق ، على سبيل المثال ، systemd ، إذا كنت تحاول حظر مكالمات النظام "الجديدة" ، فحينئذٍ نعم ... على افتراض أننا نتحدث عن نفس الشيء :)

pcmoore picture pcmoore في ١٩ أغسطس ٢٠٢٠

لكي تكون أكثر تحديدًا .. في الوقت الحالي ، يجب على أي شخص يحاول _securely_ حظر بعض syscalls أن يسمح بشكل فعال بالقائمة ، لأنه لا يمكنك التأكد مما قد تضيفه نواة أحدث. إذا استطعنا أن نطلب من libseccomp حظر عمليات syscalls غير المعروفة تلقائيًا ، فذلك يعني أنه يمكننا التبديل بأمان إلى أداة رفض صغيرة بدلاً من ذلك؟

srd424 picture srd424 في ١٩ أغسطس ٢٠٢٠
👍1

لكي تكون أكثر تحديدًا .. في الوقت الحالي ، يجب على أي شخص يحاول _securely_ حظر بعض syscalls أن يسمح بشكل فعال بالقائمة ، لأنه لا يمكنك التأكد مما قد تضيفه نواة أحدث. إذا استطعنا أن نطلب من libseccomp حظر عمليات syscalls غير المعروفة تلقائيًا ، فذلك يعني أنه يمكننا التبديل بأمان إلى أداة رفض صغيرة بدلاً من ذلك؟

آمل بصدق أن نتمكن من الوصول إلى هناك ، حيث ستكون هذه ميزة رائعة للغاية. على سبيل المثال ، يستخدم Docker حاليًا قائمة سماح وقائمتهم الافتراضية هي الآن ~ 240 syscalls (وتتزايد دائمًا).

يمكن أن يكون تأثير أداء مثل هذه القائمة الكبيرة باهظًا. لاحظ أنه يمكن التخفيف من حدته إلى حد ما باستخدام ميزة الشجرة الثنائية التي أضفناها في الإصدار 2.5.

drakenclimber picture drakenclimber في ١٩ أغسطس ٢٠٢٠

لكي تكون أكثر تحديدًا .. في الوقت الحالي ، يجب على أي شخص يحاول _securely_ حظر بعض syscalls أن يسمح بشكل فعال بالقائمة ، لأنه لا يمكنك التأكد مما قد تضيفه نواة أحدث. إذا استطعنا أن نطلب من libseccomp حظر عمليات syscalls غير المعروفة تلقائيًا ، فذلك يعني أنه يمكننا التبديل بأمان إلى أداة رفض صغيرة بدلاً من ذلك؟

لا أرى كيف يمكن أن يعمل هذا. غير معروف لـ libseccomp وغير معروف لكاتب denylist يعني عادة أشياء مختلفة. مما يعني أن المشكلة المفاهيمية لن تختفي حتى إذا كان لدى libseccomp صورة أوضح لمكالمات النظام المدعومة داخليًا.

fweimer picture fweimer في ٢١ أغسطس ٢٠٢٠

نقطة جيدة - أعتقد أننا نحتاج إلى مجموعات محددة جيدًا تم وضع علامة عليها بواسطة إصدار kernel حتى يعمل ذلك ، والذي يبدو أنه تتم مناقشته قليلاً.

srd424 picture srd424 في ٢١ أغسطس ٢٠٢٠

أعتقد أن التنفيذ لن يكون معقدًا للغاية. على سبيل المثال بالنسبة لـ amd64 ، يمكن التعبير عن عمليات syscalls "المعروفة" بالشكل n <= 181 || 186 <= ن <= 235 || 237 <= ن <= 334 || 424 <= n <= 439. ويمكن إنشاء مثل هذه التعبيرات بسهولة برمجيًا من جداول syscall.

كما تشير إلى ذلك ، فإن BPF الفعلي سيكون خاصًا بإصدار arch / ABI و kernel. في مثال x86_64 أعلاه ، لن يكون BPF سيئًا للغاية ، لكننا لسنا محظوظين بالنسبة للأقواس / الإصدارات الأخرى. بغض النظر ، هذه الآن مشكلتان تتطلبان نفس الشيء بشكل فعال لذلك أعتقد أنه شيء نريد القيام به ... لن أبدأ في القفز لأعلى ولأسفل حول مدى سهولة الأمر حتى الآن ؛ )

الجداول متصلة إلى حد ما:

>>> 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])

لقد قمت بتنفيذ عامل تصفية لمكالمات النظام "المعروفة" لـ systemd-nspawn في https://github.com/systemd/systemd/pull/16819. يحتوي https://github.com/systemd/systemd/pull/16819/commits/158e30ffd9355a7640a7276276eb9219b6c87914 على تفريغ لبعض البرامج التي تم إنشاؤها بواسطة libseccomp. عمليات التفريغ هذه طويلة ، لذا لن أكررها هنا ، لكن SCMP_FLTATR_CTL_OPTIMIZE تجعل البرنامج أكثر كفاءة ، ولكنه أطول أيضًا. يمكن جعل الأشياء أقصر بمقدار 50 مرة باستخدام مقارنات النطاق.

keszybz picture keszybz في ٢٢ أغسطس ٢٠٢٠

لقد وجدت للتو هذا الخيط للتو ، فقط أدقق لأقول إنني كنت أفكر في خطوط مماثلة وهذا بالتأكيد شيء يود Docker / runc حله أيضًا. من المحتمل أن يكون القيام بذلك باستخدام إصدار kernel الأقصى هو أفضل طريقة للقيام بذلك ، لأنه يعني أن كتاب الملفات الشخصية (وأوقات تشغيل الحاوية) لا يحتاجون إلى تتبع syscalls المضافة خارج الترتيب أو ما كان أحدث syscall في وقت كتابة هذا التقرير الملف الشخصي.

cyphar picture cyphar في ٢٧ نوفمبر ٢٠٢٠
❤1

بناءً على المناقشة أعلاه ، يبدو أن معظم (كل؟) الأشخاص هنا يعتقدون أن المشكلة رقم 11 هي الطريقة الصحيحة لحل هذه المشكلة ؛ هل لدى أي شخص مشكلة في إغلاق هذا الموضوع لصالح نقل المناقشة المستقبلية إلى الإصدار الأصلي (# 11)؟

pcmoore picture pcmoore في ٢ ديسمبر ٢٠٢٠
👍2
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

vasanthaganeshk picture vasanthaganeshk  ·  9تعليقات
drakenclimber picture drakenclimber  ·  18تعليقات
Xyene picture Xyene  ·  15تعليقات
alban picture alban  ·  5تعليقات
kloetzl picture kloetzl  ·  19تعليقات