Libseccomp: RFE: قيم إرجاع خطأ محددة بدقة أكبر

مرحبًا topimiettinen ، آسف لقد استغرق الأمر وقتًا طويلاً للوصول إلى هذا ، ولكن أعتقد أن الوقت قد حان لإصلاح هذا.

drakenclimber هذا سيكون دوزي. يجب أن تحتوي جميع واجهات برمجة تطبيقات libseccomp على إدارات في هذه المرحلة (إذا لم تكن بحاجة إلى إنشاء مشكلة لذلك) ، مع وجود بعض تعليقات "القيم السلبية عند الخطأ" المموجة يدويًا في قسم RETURN VALUE. أعتقد أننا بحاجة إلى القيام بما يلي:

• تدقيق يدويًا لكل استدعاء لواجهة برمجة التطبيقات لإنشاء قائمة بقيم الإرجاع المحتملة
• قرر ما إذا كانت قيم الإرجاع هذه منطقية ، قم بتعديل الكود إذا لم تكن كذلك
• قم بتوثيق كل قيمة إرجاع محتملة في الصفحة المرتبطة مع شرح موجز لما يشير إليه رمز الخطأ

أفكار؟

مرحبًا topimiettinen ، آسف لقد استغرق الأمر وقتًا طويلاً للوصول إلى هذا ، ولكن أعتقد أن الوقت قد حان لإصلاح هذا.

drakenclimber هذا سيكون دوزي. يجب أن تحتوي جميع واجهات برمجة تطبيقات libseccomp على إدارات في هذه المرحلة (إذا لم تكن بحاجة إلى إنشاء مشكلة لذلك) ، مع وجود بعض تعليقات "القيم السلبية عند الخطأ" المموجة يدويًا في قسم RETURN VALUE. أعتقد أننا بحاجة إلى القيام بما يلي:

* manually audit each API call to generate a list of possible return values

* decide if these return values make sense, modify the code if they don't

* document each possible return value in the associated manpage with a brief explanation of what the error code indicates

أفكار؟

دانغ .... أتفق على مضض مع كل ما كتبته أعلاه ، وخاصة الجهد المطلوب :). سيكون الحصول على رموز الإرجاع الصحيحة ثم توثيقها جهدًا كبيرًا حقًا.

ونعم ، رغم أنه ليس عملاً ساحرًا ، أعتقد أنه أمر بالغ الأهمية. لقد كنت أعمل على بعض عناصر cgroup وشاهدنا مؤخرًا تطبيق حاوية أساء فهم ميزة cgroup تمامًا ... ولكن لم يكن هناك مستند نهائي في kernel أو في أي مكان آخر لتوجيه الطريق بشكل صحيح ، لذلك جعلوه يعمل على أفضل وجه بامكانهم.

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

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

نحتاج إلى إجراء المراجعة في وقت ما ، وقد يكون كذلك الآن. كلما طال أمد الانتظار ، كلما أصبحت رموز الخطأ أقل فائدة للمتصلين ، والهدف الكامل من libseccomp هو تسهيل استخدام هذه الأشياء :)

دانغ .... أتفق على مضض مع كل ما كتبته أعلاه ، وخاصة الجهد المطلوب :). سيكون الحصول على رموز الإرجاع الصحيحة ثم توثيقها جهدًا كبيرًا حقًا.

نعم ، هذا هو أحد أسباب استمرار هذه المشكلة لفترة طويلة ، لكنني كنت أؤجلها لفترة كافية (على الأقل يمكن أن يقول drakenclimber أنه كان يؤجلها منذ أقل من عام!). في وقت لاحق اليوم (غدًا؟) سأقسم هذا إلى أجزاء / مشكلات متعددة (مع بعض الاقتراحات) لتسهيل التعامل معها إلى أجزاء.

كشيء إيجابي قليلاً ، يبدو أن libseccomp لا يستخدم سوى تسعة قيم خطأ فريدة (وفقًا لفحص أولي جدًا):

# grep -e "-E[A-Z0-9]\+" src/*.{h,c} | sed 's/.*-\(E[A-Z0-9]\+\).*/\1/' | sort -u
EACCES
EDOM
EEXIST
EFAULT
EINVAL
ENOMEM
EOPNOTSUPP
EPERM
ESRCH

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

هذا متأخر قليلاً عما هو مقصود ، ولكن فيما يلي قائمة كاملة بالوظائف التي تشكل libseccomp API:

const struct scmp_version *seccomp_version(void)
unsigned int seccomp_api_get(void)
int seccomp_api_set(unsigned int level)
scmp_filter_ctx seccomp_init(uint32_t def_action)
int seccomp_reset(scmp_filter_ctx ctx, uint32_t def_action)
void seccomp_release(scmp_filter_ctx ctx)
int seccomp_merge(scmp_filter_ctx ctx_dst, scmp_filter_ctx ctx_src)
uint32_t seccomp_arch_resolve_name(const char *arch_name)
uint32_t seccomp_arch_native(void)
int seccomp_arch_exist(const scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_arch_add(scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_arch_remove(scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_load(const scmp_filter_ctx ctx)
int seccomp_attr_get(const scmp_filter_ctx ctx, enum scmp_filter_attr attr, uint32_t *value)
int seccomp_attr_set(scmp_filter_ctx ctx, enum scmp_filter_attr attr, uint32_t value)
char *seccomp_syscall_resolve_num_arch(uint32_t arch_token, int num)
int seccomp_syscall_resolve_name_arch(uint32_t arch_token, const char *name)
int seccomp_syscall_resolve_name_rewrite(uint32_t arch_token, const char *name)
int seccomp_syscall_resolve_name(const char *name)
int seccomp_syscall_priority(scmp_filter_ctx ctx, int syscall, uint8_t priority)
int seccomp_rule_add_array(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, const struct scmp_arg_cmp *arg_array)
int seccomp_rule_add(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, ...)
int seccomp_rule_add_exact_array(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, const struct scmp_arg_cmp *arg_array)
int seccomp_rule_add_exact(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, ...)
int seccomp_notify_alloc(struct seccomp_notif **req, struct seccomp_notif_resp **resp)
void seccomp_notify_free(struct seccomp_notif *req, struct seccomp_notif_resp *resp)
int seccomp_notify_receive(int fd, struct seccomp_notif *req)
int seccomp_notify_respond(int fd, struct seccomp_notif_resp *resp)
int seccomp_notify_id_valid(int fd, uint64_t id)
int seccomp_notify_fd(const scmp_filter_ctx ctx)
int seccomp_export_pfc(const scmp_filter_ctx ctx, int fd)
int seccomp_export_bpf(const scmp_filter_ctx ctx, int fd)

... من هذه الوظائف ، نحتاج فقط إلى قلق أنفسنا بشأن إعادة الدوال "int".

المجموعات المحتملة للوظائف التي يجب أن يكون لها مسارات رمز وقيم إرجاع متشابهة.

• المجموعة أ

int seccomp_arch_exist(const scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_arch_add(scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_arch_remove(scmp_filter_ctx ctx, uint32_t arch_token)

• المجموعة ب

int seccomp_attr_get(const scmp_filter_ctx ctx, enum scmp_filter_attr attr, uint32_t *value)
int seccomp_attr_set(scmp_filter_ctx ctx, enum scmp_filter_attr attr, uint32_t value)

• المجموعة ج

int seccomp_syscall_resolve_name_arch(uint32_t arch_token, const char *name)
int seccomp_syscall_resolve_name_rewrite(uint32_t arch_token, const char *name)
int seccomp_syscall_resolve_name(const char *name)

• المجموعة د

int seccomp_rule_add_array(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, const struct scmp_arg_cmp *arg_array)
int seccomp_rule_add(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, ...)
int seccomp_rule_add_exact_array(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, const struct scmp_arg_cmp *arg_array)
int seccomp_rule_add_exact(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, ...)

• المجموعة هـ

int seccomp_notify_receive(int fd, struct seccomp_notif *req)
int seccomp_notify_respond(int fd, struct seccomp_notif_resp *resp)
int seccomp_notify_id_valid(int fd, uint64_t id)
int seccomp_notify_fd(const scmp_filter_ctx ctx)

• المجموعة F

int seccomp_load(const scmp_filter_ctx ctx)
int seccomp_export_bpf(const scmp_filter_ctx ctx, int fd)

... إذا لم تكن الوظيفة في إحدى المجموعات المذكورة أعلاه ، فمن المحتمل أن تكون فريدة في مسار الكود و / أو القيمة المرجعة.

ترجع المجموعة C فقط __NR_SCMP_ERROR.

يمكن للمجموعة D إرجاع واحدة من EINVAL و EPERM و EOPNOTSUPP و ENOMEM و EDOM و EFAULT و EEXIST.

يمكن لـ seccomp_load () إرجاع قيم EINVAL و ENOMEM و ESRCH وأيضًا قيم errno من prctl () (فقط EACCES و EFAULT و EINVAL لـ PR_SET_NO_NEW_PRIVS و PR_SET_SECCOMP) و seccomp () (EACCES ، EFAULT ، EINVAL ، دليل ENOMEM) الصفحات.

عندما يتعلق الأمر بتمرير libseccomp لأخطاء syscall إلى المتصل ، على سبيل المثال prctl () و seccomp () ، أعتقد أننا بحاجة فقط إلى إخفاء تلك الموجودة وراء قيمة خطأ واحدة (ربما ENOSYS؟) بحيث لا يتأثر libseccomp بـ أي تغييرات في النواة (أو اختلافات ABI).

إذا أصبحت هذه مشكلة في التصحيح ، فربما يمكننا تقديم سمة جديدة من شأنها إعادة قيمة errno مباشرة إلى المتصل.

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

حسنًا ، كما قلنا سابقًا ، لا نضمن حاليًا قيمًا محددة للخطأ ، فقط "قيم سلبية عند الفشل" ، لذا في حين أنه من المؤسف كسر المستخدمين الذين يقومون حاليًا بوضع افتراضات حول قيم خاطئة محددة ، أعتقد أن تغيير الأشياء لتوفير ضمان قوي على خطأ عبر إصدارات kernel و ABI في المستقبل هو مقايضة جديرة بالاهتمام.

حسنًا ، كما قلنا سابقًا ، لا نضمن حاليًا قيمًا محددة للخطأ ، فقط "قيم سلبية عند الفشل" ، لذا في حين أنه من المؤسف كسر المستخدمين الذين يقومون حاليًا بوضع افتراضات حول قيم خاطئة محددة ، أعتقد أن تغيير الأشياء لتوفير ضمان قوي على خطأ عبر إصدارات kernel و ABI في المستقبل هو مقايضة جديرة بالاهتمام.

أنا موافق.

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

ربما لم تكن فكرة التجميع هي الأفضل ، لذلك دعونا نبدأ قائمة لتتبع كل هذا _ (سأستمر في تحديث هذا أثناء تقدمنا) _:

• [x] seccomp_reset
  تُرجع حاليًا: EINVAL ، ENOMEM.

• [x] seccomp_merge
  تُرجع حاليًا: EINVAL ، EDOM ، EEXIST ، ENOMEM.

• [x] seccomp_arch_exist
  تُرجع حاليًا: EINVAL ، EEXIST.

• [x] seccomp_arch_add
  تُرجع حاليًا: EINVAL ، EEXIST ، ENOMEM ، EDOM.

• [x] seccomp_arch_remove
  تُرجع حاليًا: EINVAL ، EEXIST.

• [x] seccomp_load
  يعود حاليًا: EINVAL ، ENOMEM ، ESRCH ، ECANCELED.

• [x] seccomp_attr_get
  تُرجع حاليًا: EINVAL ، EEXIST.

• [x] seccomp_attr_set
  تُرجع حاليًا: EINVAL و EACCES و EOPNOTSUPP و EEXIST.

• [x] seccomp_syscall_resolve_name_arch
  معرفة جيدًا بالفعل ، تُرجع قيمة syscall أو __NR_SCMP_ERROR عند الفشل.

• [x] seccomp_syscall_resolve_name_rewrite
  معرفة جيدًا بالفعل ، تُرجع قيمة syscall أو __NR_SCMP_ERROR عند الفشل.

• [x] seccomp_syscall_resolve_name
  معرفة جيدًا بالفعل ، تُرجع قيمة syscall أو __NR_SCMP_ERROR عند الفشل.

• [x] seccomp_syscall_priority
  تُرجع حاليًا: EINVAL ، EDOM ، EFAULT ، ENOMEM.

• [x] seccomp_rule_add_array
  تُرجع حاليًا: EINVAL و EOPNOTSUPP و ENOMEM و EDOM و EFAULT و EEXIST.

• [x] seccomp_rule_add
  تُرجع حاليًا: EINVAL و EOPNOTSUPP و ENOMEM و EDOM و EFAULT و EEXIST.

• [x] seccomp_rule_add_exact_array
  تُرجع حاليًا: EINVAL و EOPNOTSUPP و ENOMEM و EDOM و EFAULT و EEXIST.

• [x] seccomp_rule_add_exact
  تُرجع حاليًا: EINVAL و EOPNOTSUPP و ENOMEM و EDOM و EFAULT و EEXIST.

• [x] seccomp_notify_alloc
  يتم إرجاعه حاليًا: EOPNOTSUPP و ENOMEM و EFAULT و ECANCELED. تحدد صفحة manpage بالفعل -1 عند الخطأ ، والذي يشير على الأرجح إلى seccomp () errno فقط.

• [x] seccomp_notify_receive
  تُرجع حاليًا: EOPNOTSUPP و ECANCELED. تحدد صفحة manpage بالفعل -1 عند الخطأ ، والذي يشير على الأرجح إلى seccomp () errno فقط.

• [x] seccomp_notify_respond
  تُرجع حاليًا: EOPNOTSUPP و ECANCELED. تحدد صفحة manpage بالفعل -1 عند الخطأ ، والذي يشير على الأرجح إلى seccomp () errno فقط.

• [x] seccomp_notify_id_valid
  تُرجع حاليًا: EOPNOTSUPP و ECANCELED. تحدد صفحة manpage بالفعل -ENOENT عند الخطأ (معرف غير صالح) ، والذي يشير على الأرجح إلى seccomp () errno فقط.

• [x] seccomp_notify_fd
  محددة جيدًا بالفعل ، تُرجع الإخطار fd.

• [x] seccomp_export_pfc
  يُرجع حاليًا: EINVAL و ECANCELED.

• [x] seccomp_export_bpf
  تُرجع حاليًا: EINVAL و ENOMEM و ECANCELED.

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

سأبدأ العلاقات العامة حتى نتمكن من البدء في جمع الإصلاحات والتعليقات حول التغييرات ، وسأنشرها هنا قريبًا.

بالنظر إلى الطبيعة "الخاصة" إلى حد ما لـ ENOSYS ، لدي تحفظات حول استخدام errno كعنصر تجميع kernel / libc الخاص بنا. سأضطر إلى إلقاء نظرة على القيم الأخرى ، هل لدى أي شخص أي مشاعر / أفكار قوية حول هذا؟

لا يزال هناك الكثير مفقودًا ، معظمه من تعديلات manpage وتعليقات التعليمات البرمجية (ناهيك عن الاختبار) ، ولكن يمكنك إلقاء نظرة على الفرع التالي للحصول على فكرة عما أفكر فيه:

• https://github.com/pcmoore/misc-libseccomp/tree/working-rc

بالنظر إلى الطبيعة "الخاصة" إلى حد ما لـ ENOSYS ، لدي تحفظات حول استخدام errno كعنصر تجميع kernel / libc الخاص بنا. سأضطر إلى إلقاء نظرة على القيم الأخرى ، هل لدى أي شخص أي مشاعر / أفكار قوية حول هذا؟

ماذا عن EIO؟

ماذا عن EIO؟

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

• SCMP_ERROR_UNKNOWN_SYSCALL: syscall غير معروف بواسطة libseccomp: يمكن للمتصل استخدام هذا لرفض إدخال المستخدم (على سبيل المثال ، خطأ مطبعي في اسم syscall)
• SCMP_ERROR_SYSCALL_NOT_FOR_THIS_ARCH: يُعرف syscall بواسطة libseccomp ولكنه غير متوفر هنا: يمكن للمتصل تجاهل هذا الخطأ لهذه البنية فقط
• SCMP_ERROR_API_USAGE: يكتشف libseccomp مشكلة في منطق الاستدعاء والتي لا يجب أن تحدث في التعليمات البرمجية المكتوبة بشكل صحيح: يمكن للمتصل تشغيل التأكيد ()
• SCMP_ERROR_KERNEL_OTHER: libseccomp كان جيدًا مع الإدخال وتسلسل الاستدعاءات ، لكن kernel أعاد بعض الأخطاء المحددة جيدًا مثل ENOMEM و EPERM و ENOSYS: يجب على المتصل التحقق من الخطأ لاتخاذ إجراء. في حالة معرفة libseccomp لحدوث الخطأ بسبب خطأ قام به المتصل (مثل EFAULT) ، فربما يمكن استخدام SCMP_ERROR_API_USAGE بدلاً من ذلك.
• SCMP_ERROR_KERNEL_API_USAGE: كان libseccomp جيدًا مع الإدخال وما إلى ذلك ، لكن kernel لم يعجبه لأسباب غير واضحة وواضحة. قد يشير هذا إلى تغيير kernel ، أو تعطيل التكوين ، أو خطأ في libseccomp أو المتصل ، وإدخال مستخدم غريب جدًا وما إلى ذلك. قد يكون الإجراء الخاص بالمتصل هو تسجيل الحدث وخطأ مع طلب تمرير المعلومات إلى المطورين (المتصل و / أو libseccomp) من أجل مزيد من التحليل ، وليس التأكيد () قادرة.

بدلاً من ذلك ، يمكن أن تظل واجهة برمجة التطبيقات التي تحتوي على أخطاء كما هي ، ولكن يمكن استخدام وظيفة جديدة لطلب رمز الخطأ أعلاه.

ربما يستطيعpoettering أو keszybz التعليق أيضًا.

لا أعرف ما إذا كان ذلك سيجعل الخطأ أكثر قابلية للتنفيذ. ماذا عن تمديد واجهة برمجة التطبيقات بدلاً من ذلك بوظائف لا تستخدم قيم خطأ ...

حسنًا ، قبل أن نتمكن حتى من التفكير في القيام بشيء من هذا القبيل (ولست متأكدًا من رغبتنا في القيام بذلك) ، نحتاج إلى تسوية رموز الإرجاع المستقرة والمدعومة. هذا ما نعمل عليه هنا وما نستهدفه للإصدار 2.5.

دعنا نحصل على أكواد الإرجاع المستقرة / المدعومة في الإصدار 2.5 ويمكننا أن نرى كيف تسير الأمور ، إذا احتجنا إلى القيام بشيء إضافي ، فيمكننا التفكير فيه لـ v2.6.

ماذا عن EIO؟

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

ماذا عن ECANCELED كرمز خطأ kernel الشامل؟

لدي فضول بشأن ما تعتقده drakenclimber ، لقد كنت هادئًا بشأن هذا لفترة من الوقت.

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

نفس الشيء هنا. كانت الأمور محمومة قليلاً مؤخرًا: /.

لدي فضول بشأن ما تعتقده drakenclimber ، لقد كنت هادئًا بشأن هذا لفترة من الوقت.

بالتأكيد. أرغب في قراءة الموضوع بالكامل مرة أخرى ، وبعد ذلك سأقوم بالتوافق.

ماذا عن ECANCELED كرمز خطأ kernel الشامل؟

أعترف أنني لم أكن على دراية كبيرة بـ ECANCELED. لقد بحثت بإيجاز في مصدر kernel لاستخدامه وقمت ببحث في google أيضًا. لا يوجد لدى ECANCELED أي تصادم مع libseccomp أو prctl () أو واجهات برمجة التطبيقات الأخرى التي استخدمناها ، وأعتقد أنه يمكن بشكل معقول تغليف أي خطأ يلقيه النواة علينا.

tl ؛ dr - أنا رائع مع ECANCELED باعتباره عامنا الجامع لأخطاء kernel.

عظيم شكرا. لقد حصلت على مجموعة التصحيح نصف المخبوزة ، وسأنهيها وأرسلها كممثل علاقات عامة للمراجعة.