Baru-baru ini (10-11 Juni),
konferensi ilmiah-praktis
OSDay berikutnya diadakan di Moskow. Kali ini konferensi diadakan di Institut Matematika. V.A. Steklov RAS. Secara resmi, itu didedikasikan untuk alat pengembangan untuk platform operasi dan perangkat lunak sistem. Seperti biasa, topik yang dibahas dalam konferensi tidak terbatas pada yang dinyatakan secara formal, dan masalah yang diangkat dianggap dari sudut yang berbeda dan berbagai pendekatan untuk solusi mereka dibahas. Pandangan dan pendekatan yang berbeda - inilah, menurut saya, yang membedakan konferensi dari yang lain. Jadi, misalnya, pada akhir hari kedua konferensi, secara harfiah pada penutupan tirai, Dmitry
zavalishin (
dzavalishin ), salah satu penyelenggara, memprovokasi diskusi panas bahwa bahasa pemrograman C benar-benar ketinggalan zaman dan perlu dikembangkan (termasuk sistem operasi) setidaknya dalam bahasa yang dikelola memori. Saya akan menyampaikan visi diskusi ini dan topik menarik lainnya kepada saya yang diangkat pada konferensi di artikel ini. Kepada siapa itu menarik saya bertanya di bawah kat.
Pameran
Saya akan mulai bukan dengan ulasan laporan, tetapi dengan pameran, yang merupakan bagian dari konferensi. Beberapa perusahaan telah menunjukkan perkembangannya di bidang perangkat lunak sistem. Ini terutama adalah sistem operasi, tetapi, misalnya, perusahaan SOFT MERAH, selain OS, memperkenalkan DBMS "Basis Data RED" berdasarkan pada
proyek "Firebird" . Saya sudah menyebutkan DBMS ini saat
meninjau salah satu konferensi OSDay sebelumnya . Informasi baru bagi saya adalah porting ke
arsitektur Elbrus .
Dukungan untuk arsitektur Elbrus diumumkan pada produk dari peserta pameran lainnya. Informasi yang dijalankan oleh OS Alt-Linux pada prosesor Elbrus, tentu saja, tidak menjadi berita baru bagi saya. Karyawan Basalt-SPO, seperti biasa, membawa stand berdasarkan Elbrus dan mendemonstrasikan operasi OS mereka di platform ini. Tetapi fakta bahwa pada spanduk QP OS, yang juga saya bicarakan beberapa kali dalam
tinjauan konferensi , menyatakan dukungan untuk prosesor Elbrus, mengejutkan saya. Setelah semua, kami melakukan banyak upaya untuk port Embox ke arsitektur ini, yang juga kami tulis di
hub Ternyata, sayangnya, ini bukan port lengkap untuk arsitektur e2k, peluncuran dilakukan dalam mode terjemahan perintah x86, yang, seperti yang Anda tahu, hadir dalam prosesor Elbrus.
Dukungan untuk berbagai platform perangkat keras adalah fitur dari semua peserta pameran (dengan pengecualian RusBITech-Astra, tetapi mereka, seperti yang Anda tahu, memiliki ceruk mereka sendiri). RED SOFT menunjukkan OS RED-nya (jika saya mengerti dengan benar, maka ini adalah penerus dari GosLinux, yang terdaftar dalam registri perangkat lunak domestik) di RaPi. QP OS telah menyatakan dukungan untuk ARM. Namun sejauh ini, Alt Linux adalah yang paling lintas platform. Kolega menunjukkan pekerjaan tidak hanya di domestik Elbrus dan Baikal, tetapi juga, misalnya, pada arsitektur yang relatif langka seperti
RISC-V .
Keamanan informasi
Topik keamanan perangkat lunak sangat luas. Pada konferensi tersebut beberapa kali dijelaskan bahwa ada beberapa jenis keamanan yang berbeda, lebih tepatnya definisi apa itu keamanan. Mereka berasal dari keselamatan, keamanan, keandalan bahasa Inggris, dan sebagainya. Karena itu, pembicara biasanya membicarakan keamanan seperti apa yang dimaksud saat ini. Meskipun semua orang sepakat bahwa sulit untuk berbicara tentang keamanan informasi (keamanan), jika keselamatan fungsional (safety) tidak terjamin.
Konvensi membagi menjadi keamanan - keselamatan terlihat jelas di bagian keamanan informasi. Sebagai contoh, Alexander Popov (
a13xp0p0v ), pengembang kernel Linux yang
membuat presentasi "Bagaimana STACKLEAK meningkatkan keamanan kernel Linux" pada
konferensi sebelumnya , mempresentasikan "Linux fitur fitur keamanan kernel", dan peta menunjukkan bahwa kunci untuk keamanan informasi terletak pada bidang perangkat lunak berkualitas. Bagaimanapun, sebagian besar masalah keamanan adalah standar: buffer overflows, stack overflows, tidak membersihkan stack saat kembali dari panggilan sistem, dll. Anda dapat melihat proyeknya di
github . Kemarin diterbitkan di
habrMasalah ketidakjelasan konsep keamanan perangkat lunak juga ditunjukkan dalam
laporan oleh Ekaterina Rudina dari Kaspersky Lab “Model kematangan keamanan Internet untuk hal-hal untuk membangun, mengoordinasikan dan membatasi persyaratan untuk sistem operasi”. Itu mengikuti dari laporan bahwa konsep keamanan dapat bervariasi ketika diterapkan pada area yang berbeda, dan bahkan untuk berbagai jenis perangkat dan produk. Yang jelas, yah, mengapa, misalnya, antivirus di gelang kebugaran Anda. Oleh karena itu,
Konsorsium Internet Industri , yang meliputi Kaspersky Lab, diusulkan menggunakan IoT Security Maturity Model (IoT SMM) untuk merumuskan konsep keamanan untuk kasus tertentu.
Saya pikir, karena sulitnya pemisahan antara keamanan dan keselamatan, tidak banyak laporan mengenai keamanan informasi murni. Contoh nyata dari pidato semacam itu adalah
laporan oleh komuter OpenSSL Dmitry Belyavsky, "Hosting perangkat lunak: pendekatan dari dunia Open Source". Di mana penulis berbicara tentang kesulitan mendukung standar kriptografi nasional.
Keamanan fungsional
Keselamatan fungsional (software keamanan) dalam satu bentuk atau lainnya hadir di hampir semua laporan di konferensi. Lagi pula, jika Anda melihat lebih dalam, bahkan dalam diskusi yang telah disebutkan tentang keusangan bahasa C, dipahami bahwa bahasa ini tidak aman dan dengan bantuannya sangat mudah untuk "menembak diri sendiri di kaki".
Dilihat oleh laporan di konferensi, peningkatan keselamatan fungsional (keandalan) perangkat lunak untuk peserta terlihat dalam penggunaan alat. Meskipun, mungkin ini adalah penghargaan untuk tema konferensi - alat. Oleh karena itu, sebagian besar laporan mengusulkan pendekatan instrumental yang tepat. Salah satu penyelenggara konferensi ISP RAS mengkhususkan diri dalam pengembangan alat untuk analisis kode statis dan dinamis. Sebenarnya, ISP RAS mengatur nada dengan pidato oleh
Alexander Gerasimov dengan laporan "Menggunakan Alat Analisis Program Otomatis dalam Siklus Pengembangan Perangkat Lunak Aman".
Pada topik pengembangan analisis statis, ada
laporan dari Vladimir Kozyrev dari perusahaan Advalange “Pengembangan alat untuk mengumpulkan dan menganalisis cakupan perangkat lunak di kapal”. Toolkit yang disajikan dikembangkan untuk tujuan memverifikasi perangkat lunak di dalam kapal sesuai
dengan standar DO-178C , tetapi toolkit yang sama dapat digunakan tidak hanya dalam perangkat lunak di kapal, karena kode yang dianalisis untuk cakupan adalah biasa C.
Selain laporan tentang pengembangan alat, ada beberapa laporan tentang pengalaman menggunakan alat serupa (atau sama). Sebagai contoh, sebuah
laporan oleh Pyotr Devyanin dari
RusBITech -Astra dengan judul panjang "Pengalaman dengan penggunaan alat untuk meningkatkan kepercayaan dalam mekanisme keamanan Edisi Khusus Linux OSRA Astra" berbicara tentang pengalaman penerapan alat-alat ini ke modul keamanan untuk OS mereka.
Secara alami, tidak hanya alat analisis perangkat lunak yang dipresentasikan pada konferensi, tetapi juga yang lain, dengan bantuan yang memungkinkan untuk meningkatkan keandalan perangkat lunak. Sangat menarik untuk mendengarkan
Dmitry Dagaev dengan laporan "Scalable Oberon Technologies sebagai Sarana Mengamankan Perangkat Lunak Aman untuk Sistem Kritis". Penulis laporan ini adalah kepala perancang QADA SCADA untuk pembangkit listrik tenaga nuklir. Oleh karena itu, pengalaman langsung dengan sistem dengan "peningkatan persyaratan dalam hal keamanan fungsional dan perlindungan terhadap ancaman dunia maya" (kutipan dari anotasi hingga laporannya). Untuk meningkatkan keamanan perangkat lunak, penulis menyarankan menggunakan teknologi
Oberon . Penulis bahasa Oberon,
Nikolaus Wirth , mengemukakan gagasan memperkenalkan pembatasan, yang secara signifikan mengurangi risiko penulisan perangkat lunak yang tidak aman. Pada saat yang sama, dengan bantuan penyempurnaan kompiler, penulis laporan menyarankan untuk membuat gambar yang ditujukan untuk berbagai tugas dan platform. Laporan itu sangat dekat dengan saya, ketika kami di
Embox datang dengan ide serupa tentang keterbatasan. Tetapi mereka menyarankan agar pembatasan diperkenalkan menggunakan
bahasa deskripsi modul (bahasa deklaratif dari komposisi sendiri yang ditujukan untuk tugas tertentu). Dan untuk menghasilkan artefak yang memungkinkan Anda membuat gambar untuk tugas tertentu, menurut pendapat kami, juga lebih mudah untuk menggunakan bahasa terpisah untuk menggambarkan artefak ini.
Sebagai hasilnya, penyelenggara konferensi dirangkum dalam satu bagian laporan tentang berbagai pendekatan untuk mengamankan perangkat lunak, terutama pada keamanan fungsional. Pendekatan pertama adalah menggunakan alat untuk analisis kode, yang kedua adalah menggunakan bahasa pada tingkat yang lebih tinggi dan, akhirnya, pendekatan Lab Kaspersky, yang lebih bersifat organisasi atau metodologis. Ada juga laporan tentang debugger, tetapi saya lebih baik meletakkannya di bagian terpisah, meskipun, tentu saja, debugging dapat mengurangi jumlah kesalahan dan, oleh karena itu, juga meningkatkan keandalan perangkat lunak.
Alat Debugging
Konferensi ini menghadirkan beberapa alat untuk debugging dan profil perangkat lunak sistem.
Valery Egorov dari perusahaan NTP “Cryptosoft” (pembuat
QP OS ) berbicara tentang debugger PathFinder, yang digunakan dalam hypervisor QP VMM mereka. Secara alami, semua milik mereka sendiri, dengan semua keuntungan dan kerugiannya.
Denis Silakov , Arsitek Sistem Senior,
VirtuozzoDia berbicara tentang pengalaman menemukan kesalahan berdasarkan ABRT (Alat Pelaporan Bug Otomatis). Membuat log segala sesuatu yang berguna untuk analisis, mengirim laporan jika terjadi keadaan darurat ke server, dan analisis lebih lanjut sudah ada di server.
Fedor Chemerev dari NIISI RAS berbicara tentang melacak fasilitas di OS RV keluarga Baget. Karena Baget RTOS difokuskan pada sistem embedded, dalam kasus Virtuozzo, informasi juga dikumpulkan pada mesin instrumental, dan analisis dilakukan pada server. Informasi dikumpulkan dengan menulis ke log peristiwa, sedangkan log dapat dianalisis tanpa situasi darurat.
Pendekatan modular
Pembicaraan pertama tentang alat yang mempromosikan modularitas perangkat lunak dan manfaat modularitas adalah
pembicaraan yang telah disebutkan
tentang teknologi Oberon .
Selain itu, ada tiga laporan lagi, masing-masing mengusulkan pendekatannya sendiri untuk masalah memastikan modularitas.
Dmitry Alekseev dari Eremeks LLC mempresentasikan laporan "Injeksi ketergantungan dalam perangkat lunak berorientasi komponen pada C / C ++". Di dalamnya, penulis berbicara tentang beralih konfigurasi berbagai modul kernel dari FX-RTOS OS dan juga berbagai antarmuka. Proyek berbasis makro telah dilaksanakan. Baca lebih lanjut di
artikel tentang Habr .
Saya,
Anton Bondarev , sebagai peserta dalam proyek Embox, mempresentasikan laporan "Pengalaman dalam mengembangkan dan menggunakan sistem perakitan berdasarkan bahasa pemrograman khusus", di mana saya berbicara tentang pengalaman kami dalam mengembangkan bahasa Mybuild, yang sebagian
ditulis di hub . Dalam kasus kami, modularitas dan implementasi dependensi disediakan menggunakan file terpisah, yang menjelaskan modul dalam bahasa deklaratif.
Dan yang ketiga adalah
laporan dari Mullachiev Kurbanmagomed dari ISP RAS "Tentang penggunaan pendekatan modular dalam sistem operasi tertanam". Alat ini digunakan di JetOS OS lain. Untuk deskripsi modul, bahasa YAML digunakan. Sayangnya, tidak ada contoh yang diberikan, tetapi ide yang disuarakan itu sangat menarik dan kami sedang mempertimbangkannya dalam proyek kami. Idenya adalah untuk mengekspor (menyatakan) sebuah antarmuka dan objek dapat dihubungkan melalui antarmuka ini. Gagasan itu disuarakan bahwa penulis menemukan kembali
IDL . Tapi ini tentu tidak demikian, hanya ide-ide dekat.
Sejumlah laporan tentang pendekatan modular atau komponen mungkin mengindikasikan pentingnya model komponen untuk membuat perangkat lunak yang andal. Bagaimanapun, tidak ada yang meragukan bahwa pendekatan modular dapat mengurangi kompleksitas perangkat lunak, dan karenanya keandalannya; bahwa struktur (arsitektur) perangkat lunak yang benar memberikan hasil yang luar biasa; bahwa API yang benar (pada dasarnya kontrak perangkat lunak) membuat perangkat lunak lebih didukung. Tetapi lebih mudah untuk mengatakan bahwa Anda perlu membuat antarmuka yang benar daripada mengimplementasikannya. Misalnya, laporan tentang Oberon menyarankan penggunaan modul stateless. Secara alami, ini menyelesaikan masalah, tetapi secara pribadi saya belum pernah melihat sistem nyata yang tidak memiliki status.
Kembali ke diskusi tentang usang C
Masalah menggunakan bahasa C jelas, oleh karena itu, segala macam cara untuk menyelesaikannya digunakan, dan analisis statis, dan berbagai jenis pengujian, dan banyak lagi. Sebuah pertanyaan yang masuk akal muncul: mengapa menghabiskan begitu banyak usaha?
Karena diskusi terbuka dan mikrofon disediakan untuk semua orang, jelas bahwa beberapa peserta konferensi sepenuhnya mendukung gagasan ini, dan beberapa menyatakan berbagai keraguan bahwa bahasa C akan menjadi sesuatu dari masa lalu, setidaknya di bidang pemrograman sistem dalam waktu dekat.
Pertama, saya akan memberikan argumen dari bagian peserta yang mendukung ide tersebut. Jelas, gagasan itu didukung oleh Dmitry Dagaev, penulis laporan tentang Oberon. Sebagai argumen, dia mengutip foto di mana, dalam gambar dengan Nikolaus Wirth, dia memegang poster dengan tulisan bahwa Anda hanya perlu mengajar pemrograman di Oberon. Peserta lain dalam diskusi mengemukakan tesis bahwa
arsitektur von Neumann agak ketinggalan jaman, well, setidaknya Anda dapat menggunakan memori yang ditandai, seperti dalam arsitektur Elbrus. Dan itu bukan tentang arsitektur Elbrus, tetapi tentang tren modern dalam arsitektur ARM, dan Alexander Popov, sudah disebutkan, mengatakan ini. Secara alami, ada segera mereka yang ingin menulis OS, beberapa fungsi yang akan diimplementasikan dalam perangkat keras. Serangkaian peserta, mengembangkan topik menggunakan bahasa lain, secara alami, disarankan menggunakan bahasa pemrograman fungsional. Mengembangkan tema bahasa, kami sampai pada kesimpulan bahwa di negara kami tidak ada alat pengembangan yang disertifikasi, misalnya, kompiler untuk ARM, dan kompiler yang diizinkan untuk digunakan mungkin berisi penanda. Oleh karena itu, jelas bahwa Anda harus terlebih dahulu membuat kompiler, dan baru kemudian menulis perangkat lunak berdasarkan itu, termasuk sistem operasi.
Argumen bagian kedua dari peserta dalam diskusi tidak begitu mendukung penggunaan bahasa C, melainkan mereka menjelaskan mengapa bahasa ini masih menjadi standar untuk membuat kernel OS. Argumen semacam itu terdengar. Sintaks bahasa C menyiratkan kontrol penuh dan eksplisit oleh programmer dari semua yang ada dalam program, termasuk alokasi memori, yang memungkinkan Anda untuk membuat algoritma yang sangat hemat sumber daya. Bahasa C memang didukung oleh alat pengembangan, misalnya, gcc. Sintaks bahasanya sangat sederhana dan tidak asing bagi banyak orang.
Saya sangat menyukai alegori dengan pesawat ruang angkasa dan jalan-jalan tua. Beranjak dari itu, mobil biasa sekarang digunakan, yang mungkin tidak terlalu baik, mencemari lingkungan dan memiliki tingkat kecelakaan yang besar. Tetapi untuk beralih ke beberapa supercar tak berawak, Anda mungkin perlu tumbuh dengan mereka, membangun jaringan jalan dengan kualitas yang sesuai, mengisi bahan bakar, mengembangkan algoritma, dan sebagainya. Pekerjaan di bidang ini sedang dilakukan, tetapi untuk mengambil dan melarang mobil tua seperti ini tidak mungkin berhasil.
Saya benar-benar setuju, pertama Anda perlu mengembangkan industri dan melatih spesialis, dan ini adalah proses yang sangat panjang, untuk sekarang Anda harus menggunakan banyak perangkat lunak yang sudah dikembangkan di C, karena jauh lebih dapat diandalkan dan lebih banyak disadap daripada yang baru dibuat, walaupun dengan teknologi canggih. Memang, meski tidak pada diskusi ini, peringatan semacam itu terdengar di konferensi. Sebagai contoh, penulis laporan hosting perangkat lunak kriptografi, Dmitry Belyavsky, ketika ditanya apa yang perlu diketahui oleh pengembang keamanan, menjawab, "jangan pernah menulis sendiri kriptografi." Dan Dmitry Shevtsov dari FSTEC, meminta saya untuk lebih berhati-hati dalam mendukung perangkat lunak yang dikembangkan.
Tentang spesialis pelatihan, ini mungkin pertanyaan paling penting: apa yang para ahli “pikirkan” - perangkat lunak akan dikembangkan mengenai hal itu, sangat mungkin bahwa bahasa C menjadi standar de facto untuk OS, karena memiliki UNIX dan Minix (dan mungkin itu sebabnya yang disusun untuk pengembangan UNIX). Oleh karena itu, proyek untuk mengajar anak sekolah dan siswa untuk memprogram dalam bahasa Oberon
Informatics 21 dapat membuahkan hasil, namun, banyak waktu harus berlalu.
Kesimpulan
Seperti yang saya katakan di bagian pendahuluan, konferensi ini memungkinkan Anda untuk berbagi ide, berdiskusi dan berdiskusi. Beberapa pendekatan disajikan pada banyak masalah, misalnya, tentang perangkat lunak modular dan perangkat lunak aman. Selain itu, penyelenggara konferensi secara sadar memanggil pembicara dengan pendekatan berbeda dan ini membuat konferensi lebih menarik. Dan tentu saja, konferensi ini sangat terbuka, seperti yang dikatakan Dmitry Zavalishin selama diskusi tentang bahasa C, "Lima menit kejayaan bagi semua orang."
PS
Saya baru saja membaca
sebuah artikel di hub yang disebut "Media Teknis sebagai Bazaar" . Ini menjelaskan betapa pentingnya memiliki beberapa pendapat yang berbeda. Saya mengusulkan untuk melanjutkan diskusi tentang bahasa C di Habré. Sebagai contoh, sangat menarik untuk mengetahui apakah ada solusi industri lintas platform berkarat atau pergi?