في الآونة الأخيرة (من 10 إلى 11 يونيو) ، تم عقد المؤتمر العلمي
والتشغيلي التالي لـ
OSDay في موسكو. هذه المرة تم عقد المؤتمر في المعهد الرياضي. VA ستيكلوف RAS. بشكل رسمي ، كانت مخصصة لأدوات التطوير لأنظمة التشغيل وبرامج النظام. كالعادة ، لم تقتصر الموضوعات التي تم تناولها في المؤتمر على ذكرها رسميًا ، وتم النظر في القضايا المثارة من زوايا مختلفة وتمت مناقشة الطرق المختلفة لحلها. وجهات نظر وأساليب مختلفة - وهذا ، في رأيي ، هو ما يميز المؤتمر عن الباقي. لذلك ، على سبيل المثال ، في نهاية اليوم الثاني للمؤتمر ، حرفيًا في نهاية الستار ،
أثار ديمتري
زافاليشين (
دزافاليشين ) ، أحد المنظمين ، نقاشًا ساخنًا حول حقيقة أن لغة البرمجة C قد عفا عليها الزمن وكان من الضروري تطويرها (بما في ذلك أنظمة التشغيل) على الأقل في اللغات التي تديرها الذاكرة. سوف أقدم رؤيتي لهذه المناقشة وغيرها من الموضوعات التي تهمني والتي أثيرت في المؤتمر في هذا المقال. إلى من المثير للاهتمام أنني أسأل تحت القات.
معرض
لن أبدأ بمراجعة التقارير ، ولكن مع المعرض ، الذي يعد جزءًا من المؤتمر. أظهرت العديد من الشركات تطورها في مجال برامج النظام. هذه هي أنظمة التشغيل بشكل أساسي ، ولكن ، على سبيل المثال ، قدمت شركة RED SOFT ، إلى جانب نظام التشغيل ، قاعدة بيانات RMS "قاعدة بيانات RED" على أساس
مشروع Firebird . لقد ذكرت بالفعل نظام إدارة قواعد البيانات هذا أثناء
مراجعة أحد مؤتمرات OSDay السابقة . معلومات جديدة بالنسبة لي هي أنه تم نقلها إلى
العمارة Elbrus .
تم الإعلان عن دعم هندسة Elbrus في منتجات العارضين الآخرين. المعلومات التي يعمل عليها نظام التشغيل Alt-Linux على معالجات Elbrus ، بالطبع ، لم تصبح أخبارًا لي. جلب موظفو Basalt-SPO ، كالعادة ، موقفا قائما على Elbrus وأظهروا تشغيل نظام التشغيل الخاص بهم على هذه المنصة. لكن حقيقة أن إعلان QP OS ، الذي تحدثت عنه أيضًا عدة مرات في
مراجعات المؤتمر ، أعلن دعمه لمعالجات Elbrus ، فاجأني. بعد كل شيء ، بذلنا الكثير من الجهود لتوصيل Embox إلى هذه البنية ، والتي كتبنا عنها أيضًا على
المحور اتضح أنه ، لسوء الحظ ، ليس هذا منفذًا كاملًا لهندسة e2k ، فقد تم الإطلاق في وضع ترجمة الأوامر x 86 ، والذي ، كما تعلم ، موجود في معالجات Elbrus.
كان الدعم لمختلف منصات الأجهزة ميزة لجميع العارضين (باستثناء RusBITech-Astra ، لكنهم ، كما تعلمون ، لديهم مكانة خاصة بهم). أظهر RED SOFT نظام التشغيل RED الخاص به (إذا فهمت بشكل صحيح ، فهذا هو خليفة GosLinux ، المدرج في سجل البرنامج المحلي) على RaPi. أعلن QP OS دعم ARM. لكن إلى حد بعيد ، كان Alt Linux هو النظام الأساسي المتقاطع. أظهر الزملاء العمل ليس فقط في Elbrus و Baikal المحلي ، ولكن أيضًا ، على سبيل المثال ، في بنية نادرة نسبيًا مثل
RISC-V .
أمن المعلومات
موضوع أمان البرنامج واسع جدًا. في المؤتمر عدة مرات ، تم توضيح أن هناك عدة أنواع مختلفة من الأمن ، وبالتحديد أكثر تعاريف لما هو الأمن. إنهم يأتون من السلامة والأمان والموثوقية الإنجليزية وما إلى ذلك. لذلك ، تحدث المتحدث عادة عن أي نوع من الأمن في السؤال في الوقت الراهن. على الرغم من أن الجميع وافقوا على أنه من الصعب التحدث عن أمن المعلومات (الأمن) ، إذا لم يتم ضمان السلامة الوظيفية (السلامة).
كانت اتفاقية التقسيم إلى أمان - واضحة للعيان في القسم الخاص بأمان المعلومات. على سبيل المثال ، قدم ألكسندر بوبوف (
a13xp0p0v ) ، وهو مطور نواة Linux الذي
قدم عرضًا تقديميًا "كيف تعمل STACKLEAK على تحسين أمان نواة Linux" في
مؤتمر سابق ، تقديم
تقرير "خريطة ميزات أمان نواة Linux" ، وتوضح الخريطة أن مفتاح أمان المعلومات يكمن في مجالات البرمجيات ذات الجودة. بعد كل شيء ، تكون معظم مشكلات الأمان قياسية: تجاوزات المخزن المؤقت ، تجاوزات مكدس الذاكرة المؤقتة ، عدم مسح المكدس عند الرجوع من مكالمة النظام ، وما إلى ذلك. يمكنك عرض مشروعه على
github . نشرت أمس على
هابركما تم توضيح مشكلة غموض مفهوم أمان البرمجيات في
تقرير أعدته إيكاترينا رودينا من Kaspersky Lab بعنوان "نموذج نضج أمن الإنترنت من أجل إنشاء متطلبات وتنسيقها والحد منها لأنظمة التشغيل". يتبع ذلك من التقرير أن مفهوم الأمان يمكن أن يختلف عند تطبيقه على مناطق مختلفة ، وحتى على أنواع مختلفة من الأجهزة والمنتجات. وهذا واضح ، لماذا ، على سبيل المثال ، مضاد فيروسات على سوار اللياقة البدنية الخاص بك. لذلك ، اقترح
اتحاد الإنترنت الصناعي ، والذي يتضمن Kaspersky Lab ، استخدام IoT Security Maturity Model (IoT SMM) لصياغة مفهوم الأمان لحالة معينة.
أعتقد أنه نظرًا لصعوبة الفصل بين الأمن والسلامة ، لم يكن هناك الكثير من التقارير حول أمان المعلومات النقي. مثال حي على مثل هذا الخطاب كان
تقرير أعده OpenSSL ديمتري بيليفسكي ، "استضافة البرمجيات: نهج من عالم المصدر المفتوح". تحدث المؤلف عن صعوبات دعم معايير التشفير الوطنية.
السلامة الوظيفية
كانت السلامة الوظيفية (برامج السلامة) بشكل أو بآخر موجودة في جميع التقارير تقريبًا في المؤتمر. بعد كل شيء ، إذا كنت تبدو أعمق ، حتى في المناقشة التي سبق ذكرها حول تقادم اللغة C ، كان من المفهوم أن هذه اللغة غير آمنة وبمساعدتها ، من السهل جدًا "إطلاق النار على نفسك".
بناءً على التقارير الواردة في المؤتمر ، فإن تحسين السلامة الوظيفية (الموثوقية) للبرامج الخاصة بالمشاركين يظهر في استخدام الأدوات. ومع ذلك ، ربما يكون هذا تكريمًا للموضوع المعلن للمؤتمر - الأدوات. لذلك ، اقترحت الغالبية العظمى من التقارير على وجه التحديد نهجا فعالا. أحد منظمي المؤتمر ISP RAS متخصص في تطوير أدوات لتحليل الشفرة الثابتة والديناميكية. في الواقع ، عيّن ISP RAS النغمة بخطاب ألقاه
ألكساندر جيراسيموف بتقرير "استخدام أدوات تحليل البرنامج التلقائي في دورة تطوير البرمجيات الآمنة".
حول موضوع تطوير أجهزة التحليل الثابتة ، كان هناك
تقرير من فلاديمير كوزيريف من شركة Advalange بعنوان "تطوير أدوات لجمع وتحليل تغطية البرامج على متن الطائرة". تم تطوير مجموعة الأدوات المقدمة لغرض التحقق من البرنامج على متن الطائرة وفقًا
لمعيار DO-178C ، ولكن يمكن استخدام مجموعة الأدوات نفسها ليس فقط في البرامج الموجودة على متن الطائرة ، لأن الشفرة التي تم تحليلها للتغطية عادية C.
بالإضافة إلى التقارير المتعلقة بتطوير الأدوات ، كان هناك العديد من التقارير حول تجربة استخدام أدوات مماثلة (أو نفس الأدوات). على سبيل المثال ، تحدث
تقرير لبيوتر ديفيانين من
RusBITech -Astra بعنوان طويل "تجربة مع استخدام الأدوات لزيادة الثقة في آليات الأمان الخاصة بإصدار OSRA Astra Linux Special Edition" عن تجربة تطبيق هذه الأدوات على وحدة أمان لنظام التشغيل الخاص بهم.
بطبيعة الحال ، لم يتم تقديم أدوات تحليل البرمجيات فقط في المؤتمر ، ولكن أيضًا الأدوات الأخرى ، والتي من خلالها ساعدت على زيادة موثوقية البرنامج. كان من الممتع للغاية الاستماع إلى
ديمتري داجاييف من خلال تقرير "Scalable Oberon Technologies كوسيلة لتأمين البرمجيات الآمنة للأنظمة الحرجة". مؤلف التقرير هو المصمم الرئيسي لـ SCADA QMS لمحطات الطاقة النووية. لذلك ، تجربة مباشرة مع أنظمة ذات "متطلبات متزايدة فيما يتعلق بالأمن الوظيفي والحماية من التهديدات السيبرانية" (اقتباس من الشرح إلى تقريره). لزيادة أمان البرنامج ، يقترح المؤلف استخدام تقنية
Oberon . وضع مؤلف لغة أوبيرون ،
نيكولاس ويرث ، فكرة إدخال قيود ، مما يقلل بشكل كبير من خطر كتابة برامج غير آمنة. في الوقت نفسه ، وبمساعدة تحسين المترجم ، يقترح مؤلف التقرير إنشاء صور تهدف إلى مهام ومنصات مختلفة. كان التقرير قريبًا جدًا مني ، حيث توصلنا في
Embox إلى أفكار مشابهة حول القيود. لكنهم اقترحوا إدخال قيود باستخدام
لغة وصف الوحدة (
لغة تعريفية للتكوين الخاص بها تهدف إلى مهمة محددة). ولإنشاء أدوات تسمح لك بإنشاء صور لمهمة محددة ، في رأينا ، من الأسهل أيضًا استخدام لغة منفصلة لوصف هذه القطع الأثرية.
نتيجة لذلك ، قام منظمو المؤتمر بإيجاز في قسم واحد بإبلاغهم عن الطرق المختلفة لتأمين البرمجيات ، وبشكل أساسي حول الأمن الوظيفي. تتمثل الطريقة الأولى في استخدام أدوات لتحليل الأكواد ، والثاني هو استخدام لغات ذات مستوى أعلى ، وأخيراً ، منهج Kaspersky Lab ، والذي يعتبر تنظيميًا أو منهجيًا إلى حد ما. كان هناك أيضًا تقرير حول مصحح الأخطاء ، لكن من الأفضل وضعه في قسم منفصل ، على الرغم من أن تصحيح الأخطاء يمكن أن يقلل بالطبع عدد الأخطاء ، وبالتالي يزيد من موثوقية البرنامج.
أدوات التصحيح
قدم المؤتمر العديد من الأدوات لتصحيح الأخطاء وبرامج نظام الملفات.
تحدث فاليري إيجوروف من شركة NTP "Cryptosoft" (منشئ
نظام تشغيل QP OS ) عن مصحح أخطاء PathFinder ، والذي يُستخدم في برنامج مراقبة QP VMM الخاص بهم. بطبيعة الحال ، كل ما لديهم ، مع كل المزايا والعيوب التي تلت ذلك.
دينيس سيلاكوف ، كبير مهندسي الأنظمة ،
Virtuozzoتحدث عن تجربة العثور على الأخطاء على أساس ABRT (أداة الإبلاغ التلقائي عن الأخطاء). بناء سجل بكل ما يمكن أن يكون مفيدًا للتحليل ، وإرسال تقرير في حالة الطوارئ إلى الخادم ، والتحليل الإضافي الموجود بالفعل على الخادم.
تحدث Fedor Chemerev من NIISI RAS عن مرافق البحث عن المفقودين في نظام التشغيل الخاص برفقة عائلة Baget. نظرًا لأن Baget RTOS يركز على الأنظمة المدمجة ، في حالة Virtuozzo ، يتم أيضًا جمع المعلومات على الجهاز الآلي ، ويتم إجراء التحليل على الخادم. يتم جمع المعلومات عن طريق الكتابة إلى سجل الأحداث ، بينما يمكن تحليل السجل دون حالات الطوارئ.
نهج وحدات
الحديث الأول عن الأدوات التي تعزز نمطية البرمجيات وفوائدها هو
الحديث الذي سبق ذكره
حول تقنية أوبيرون .
بالإضافة إلى ذلك ، كان هناك ثلاثة تقارير أخرى ، اقترح كل منها نهجه الخاص تجاه مشكلة ضمان التقيد.
قدم Dmitry Alekseev من Eremeks LLC تقرير "حقن التبعية في البرامج الموجهة للمكونات على C / C ++". في ذلك ، تحدث المؤلف عن تبديل تكوين وحدات مختلفة من نواة نظام التشغيل FX-RTOS وكذلك واجهات مختلفة. تم تنفيذ مشروع قائم على الماكرو. اقرأ المزيد في
مقالة هبر .
قمت
أنتون بونداريف ، كمشارك في مشروع Embox ، بتقديم تقرير "تجربة في تطوير واستخدام نظام التجميع على أساس لغة برمجة متخصصة" ، تحدثت فيه عن تجربتنا في تطوير لغة Mybuild ، والتي تمت
كتابتها جزئيًا
على المحور . في حالتنا ، يتم توفير نمطية التبعيات وتطبيقها باستخدام ملفات منفصلة ، تصف الوحدات النمطية بلغة تعريفية.
والثالث هو
تقرير من Mullachiev Kurbanmagomed من ISP RAS "حول استخدام نهج وحدات في أنظمة التشغيل المدمجة". تم استخدام هذه الأداة في نظام تشغيل JetOS آخر. لوصف الوحدات ، يتم استخدام لغة YAML. لسوء الحظ ، لم يتم تقديم أية أمثلة ، لكن الفكرة التي تم التعبير عنها كانت مثيرة للاهتمام للغاية ونحن ندرسها في مشروعنا. الفكرة هي تصدير (إعلان) واجهة ويمكن توصيل الكائنات عبر هذه الواجهة. تم التعبير عن الفكرة بأن المؤلفين قاموا بإعادة اختراع
IDL . ولكن هذا ليس هو الحال بالتأكيد ، مجرد أفكار قريبة.
يشير مثل هذا العدد من التقارير حول النهج المعياري أو المكون إلى أهمية نموذج المكون لإنشاء برامج موثوقة. بعد كل شيء ، لا أحد يشك في أن النهج المعياري يمكن أن يقلل من تعقيد البرمجيات ، وبالتالي موثوقيتها ؛ أن البنية الصحيحة (الهندسة المعمارية) للبرنامج تعطي نتائج مذهلة ؛ أن واجهة برمجة التطبيقات الصحيحة (عقد البرمجيات بشكل أساسي) تجعل البرنامج أكثر دعمًا. لكن من السهل القول أنك بحاجة إلى إنشاء الواجهة الصحيحة بدلاً من تنفيذها. على سبيل المثال ، يشير تقرير عن Oberon إلى استخدام وحدات بدون جنسية. بطبيعة الحال ، هذا يحل المشكلة ، لكنني شخصياً لم أر قط نظامًا حقيقيًا لا يوجد به دولة.
العودة إلى المناقشة حول C القديمة
مشاكل استخدام لغة C واضحة ، لذلك ، يتم استخدام كل أنواع الطرق لحلها ، والمحللات الثابتة ، وأنواع مختلفة من الاختبارات ، وأكثر من ذلك بكثير. يطرح سؤال معقول: لماذا تنفق الكثير من الجهد؟
نظرًا لأن النقاش كان مفتوحًا وتم توفير ميكروفون للجميع ، فقد كان واضحًا أن بعض المشاركين في المؤتمر أيدوا هذه الفكرة تمامًا ، وأعرب البعض عن شكوك مختلفة في أن لغة C ستكون شيئًا من الماضي ، على الأقل في مجال برمجة النظام في المستقبل القريب.
أولاً ، سأقدم حجج جزء من المشاركين الذين أيدوا الفكرة. من الواضح أن الفكرة كانت مدعومة من قبل ديمتري داجاييف ، مؤلف التقرير عن أوبيرون. وكحجة ، فقد استشهد بصورة توضح أين ، في الصورة مع نيكولاس ويرث ، يحمل ملصقًا به نقش تحتاجه لتدريس البرمجة على أوبرون فقط. طرح مشاركون آخرون في المناقشة أطروحة مفادها أن
بنية فون نيومان عفا عليها الزمن إلى حد ما ، حسنًا ، على الأقل يمكنك استخدام الذاكرة الموسومة ، كما هو الحال في هندسة البروس. ولم يكن الأمر متعلقًا بعمارة Elbrus ، ولكن عن الاتجاهات الحديثة في هندسة ARM ، وألكسندر بوبوف ، الذي سبق ذكره ، قال هذا. بطبيعة الحال ، كان هناك على الفور أولئك الذين أرادوا كتابة نظام التشغيل ، وسيتم تنفيذ بعض وظائفها في الأجهزة. من الطبيعي أن تقترح مجموعة كاملة من المشاركين وضع لغة استخدام لغة أخرى استخدام لغات البرمجة الوظيفية. عند تطوير موضوع اللغة ، توصلنا إلى استنتاج مفاده أنه في بلدنا لا توجد أدوات تطوير معتمدة ، على سبيل المثال ، قد يحتوي برنامج التحويل البرمجي لـ ARM والمترجمين المسموح باستخدامهم على إشارات مرجعية. لذلك ، من الواضح أنه يجب عليك أولاً إنشاء برنامج التحويل البرمجي ، وعندئذٍ فقط كتابة برنامج يستند إليه ، بما في ذلك أنظمة التشغيل.
لم تكن حجج الجزء الثاني من المشاركين في المناقشة مؤيدة لاستخدام لغة C كثيرًا ، بل شرحوا لماذا لا تزال هذه اللغة هي المعيار لإنشاء نواة نظام التشغيل. بدا مثل هذه الحجج. يتضمن بناء جملة اللغة C سيطرة كاملة وصريحة من قبل مبرمج كل شيء في البرنامج ، بما في ذلك تخصيص الذاكرة ، والذي يسمح لك بإنشاء خوارزميات فعالة للغاية من حيث الموارد. اللغة C مدعومة بالفعل بأدوات التطوير ، على سبيل المثال ، gcc. بناء جملة اللغة بسيط جدًا ومألوف لدى عدد كبير جدًا من الأشخاص.
أنا حقا أحب الرمز مع سفن الفضاء والطرق القديمة. انطلاقا من ذلك ، يتم استخدام السيارات العادية الآن ، والتي ربما ليست جيدة جدا ، وتلوث البيئة ولها معدل حوادث كبير. ولكن من أجل التبديل إلى بعض السيارات الخارقة غير المأهولة ، ربما تحتاج إلى النمو إليها ، وإنشاء شبكة من الطرق ذات الجودة المناسبة ، والتزود بالوقود ، وتطوير الخوارزميات ، وما إلى ذلك. يجري العمل في هذه المناطق ، ولكن من غير المرجح أن تنجح السيارات القديمة وحظرها.
أوافق تمامًا ، أولاً ، تحتاج إلى تطوير الصناعة وتدريب المتخصصين ، وهذه عمليات طويلة جدًا ، حيث يتعين عليك الآن استخدام مجموعة من البرامج المطورة بالفعل في C ، لأنه أكثر موثوقية وأكثر تصحيحًا من التقنيات التي تم إنشاؤها حديثًا ، وإن كان ذلك باستخدام التقنيات المتقدمة. في الواقع ، على الرغم من أن هذه التحذيرات لم تظهر في هذا النقاش ، إلا أنه بدا في المؤتمر. على سبيل المثال ، أجاب مؤلف تقرير استضافة برامج التشفير ، ديمتري بيليفسكي ، عندما سئل عما يجب على مطور الأمان معرفته ، "لم يكتب التشفير بنفسك أبدًا". وطلب مني ديمتري شيفتسوف من شركة FSTEC الاهتمام أكثر بدعم البرنامج المطور.
حول تدريب المتخصصين ، قد يكون هذا هو السؤال الأكثر أهمية: ما الذي "يفكر" الخبراء - سوف يتم تطوير البرنامج عليه ، فمن المحتمل أن تصبح لغة C هي المعيار الفعلي لنظام التشغيل ، نظرًا لأن لديها UNIX و Minix (وربما لهذا السبب التي تم وضعها لتطوير UNIX). لذلك ، فإن مشروع تعليم تلاميذ المدارس والطلاب على البرمجة بلغة أوبرون
للمعلوماتية 21 يمكن أن يؤتي ثماره ، ومع ذلك ، يجب أن يمر الكثير من الوقت.
استنتاج
كما قلت في المقدمة ، يسمح لك هذا المؤتمر بمشاركة الأفكار والمناقشة والمناقشة. تم تقديم عدة طرق حول العديد من المشكلات ، على سبيل المثال ، حول البرامج المعيارية والبرامج الآمنة. علاوة على ذلك ، فإن منظمي المؤتمر يدعون المتحدثين عن عمد بطرق مختلفة وهذا يجعل المؤتمر أكثر إثارة للاهتمام. وبالطبع ، فإن المؤتمر مفتوح للغاية ، كما قال ديمتري زافاليشين أثناء المناقشة حول لغة C ، "خمس دقائق من المجد للجميع".
PS
لقد قرأت للتو
مقالة على مركز يسمى "الوسائط التقنية كسوق" . وهذا ما يفسر مدى أهمية وجود عدة آراء مختلفة. أقترح مواصلة النقاش حول لغة C على حبري. على سبيل المثال ، من المثير للاهتمام للغاية معرفة ما إذا كانت هناك حلول صناعية عبر منصة على الصدأ أو الذهاب؟