Meltdown / Spectre

Meltdown / Spectre.
Niyə təhlükəsizlik problemləri? Sistemlərimiz niyə təhlükəsiz deyil?

İnternetin varlığı ucbatından bütün sistemlərimiz demək olar ki, dünyaya açıq haldadır. Bir serveriniz varsa, ən bəsit halda SSH üçün 22 nömrəli portunuz açıqdırsa, sistem loqlarına nəzər yetirdiyinizdə bəsit login girişi atakı görməyiniz mümkündür. Daima hücum altındayıq çünki. Yəni davamlı olaraq sistemlərimiz üzərində login testləri edilir. Bəs yaxşı niyə bu hücumlar çox vaxt müvəffəqiyyətlə nəticələnir?

Təməl səbəblərdən biri C dilinə əsaslanır. Əslində C dilinin bir günahı yoxdur və C++ dili də C dilinin bu xüsusiyyətlərini miras olaraq alır. Əslində problemlərə səbəb olan C dilinin bu iki xüsusiyyəti kafidir: a) array accessinin sərhədlərinə avtomatik nəzarət edilmir, b) array yaddaş daxilində tipi müəyyən edilməmiş bir pointer. Bu iki səbəbdən ötrü array sərhədlərinin daşmasını tətikləyən bir müdaxilə, stack üzərində informasiyalar yazıb hücum kodunun işə salınmasına səbəb ola bilər (bufer overrun boşluğu).
İddia edilən təhlükəsizlik məsələsi böyük ölçüdə programlama dilinin struktural problemidir. C dilində, pascalda olduğu kimi array sərhədlərinə hər accessdə nəzarət edilsəydi və referansların tipləri müəyyən edilmiş olsaydı belə bir boşluğun varlığı mümkün olmayacaqdı. Bunun qarşısını almaq məqsədilə iOS, MS Windows, GNU/Linux ƏS-lərdə, iş prosesi vaxtı nəzarətlər edilsəydi, təbii olaraq əməliyat sistemlərimiz bir miqdar daha yavaş işləyəcəkdi. Bəs bugün Meltdownun qarşısını almaq üçün onsuz da sistemlərimizi yavaşlatmayacağıqmı?

Təbii ki, hər təhlükəsizlik boşluğu belə bir boşluqdan qaynaqlanmır. Məsələn, SQL injection programlama dillərinin başqa bir zəifliyinə, tip sistemlərinin zəif olmasına bağlıdır. Problem budur ki, bir login inputu ilə SQL sorğusu da eyni tipdə, string tipində olur. Əslində bu iki şey fərqli tipdə olmalı idi. Burada mövzubəhs məsələ, programlama dilinin tip sisteminin bir boşluğudur. Mətn bir şeydir, SQL əmri başqa bir məlumat tipidir. Bu ikisinin eyni formada şərh edilməsi bu təhlükəsizlik boşluğuna səbəb olur.

Meltdown və Spectre boşluqları köhnələrdən biraz fərqli olaraq birbaşa bir dil probleminə bağlı deyil. Spectre boşluğu, javascript dilində yazılan bir kod ilə brauzer üzərindən belə exploit edilə bilinir.

Yenə də Meltdown və Spectre-ə gələsi olsaq maraqlı bir şəkildə həllər də programlama dili, yəni complier ilə həll edilməyə çalışılır. Complierlər, Meltdown və Spectre-ə səbəb olacaq maşın kodu əməliyyat array-ları yaratmamağa çalışacaq. On milyardlarla prosessoru bu dəqiqə dəyişdirə bilməyəcəyimizə görə, başqa çarə də yoxdur. LLVM və GCC C dili complierləri istehsal etdikləri maşın kodlarında “retpoline” üsulu ilə Meltdown/Spectre boşluqlarını bağlamağa çalışırlar.

Legacy problemi.

45 illik bir programlama dili ilə yazılan ən az 30 illik əməliyyat sistemləri ilə kompüter sistemlərimizi idarə etməyə çalışırıq. Bugünki komputerlərin sayısı o dövrünkindən ən az min qat çox, sürətləri, yaddaşları minlərlə qat artmış vəziyyətdədir. Bəhs etdiyimi sistemlər təkmilləşdirildikdə çox az cihaz internetə bağlı idi, indi demək olar ki hamsı qoşuludur. Vəziyyət dəyişdi, avadanlıq dəyişdi amma program texnologiyamız kifayət qədər dəyişmədi.
Programı dəyişdirmək avadanlığı dəyişdirmək qədər asan deyil.

Gələcək üçün həll üsulları.

Kompüter olaraq Raspberry Pi istifadə edirsinizsə, Meltdown və Spectre boşluqlarından narahat olmağınıza əsas yoxdur. Pi-dəki ARM prosessoru bu boşluqlara icazə vermir. Raspberry Pi-dəki ARM bəsit bir RISC (Reduced Instrction Set Computer) prosessoru olduğu üçün speculative execution etməyib bu hücumdan qurtulur.

Avadanlığımızda da bir qarabasmamız var: CISC. x86 prosessoru arxitekturası keçmişdən qalmış bir qarabasmadır. Qarışıq amma güclü komandaları ilə maşın kodunun manual olaraq yazılmasını asanlaşdırır. 1980-ci illərdə Stanford və Berkeleydə təkmilləşdirilən RISC arxitekturası bəsit, tək periodda işləyən komandalar prosessorda çoxlu register istifadə etdiyi üçün eyni hesablama işini daha az tranzistor və daha az enerji istifadə edərək edər. Bəsit komandaları ilə RISC arxitekturası da prosessorun “pipeline” boru xətti prosesini asanlaşdırır. Prosessor komandaları addım-addım prosessor içindəki bir boru xəttindən irəliləyir və eyni anda birdən çox komanda qiymətləndirilir. Bu da bəzən komandaların qeyri-adi (out of order) qiymətləndirilməsinə səbəb ola bilər.

Məsələn, bir atlama (Jump) komandası compile edilərkən, bununla birlikdə bir başqa komanda da compile edilir. Bu da “branch delay slot” olaraq bilinir. Maşın dilində yazılacaq programlar üçün programçılıq çətin bir sənət halına gəlir. Ancaq maşın dilində kim program yazır ki? Compilerlər yazılan programları compile edərək maşın dilinə çevirir. Yəni bu çətin işi compilerlər edir.

İntel və davamçıları uzun müddət CISC üçün sinə gərdi. Ancaq RISC qazandı. RISC arxitekturasının daha aşağı elektrik istifadəsi səbəbindən dünyadaki prosessorların böyük hissəsi (95% ?) RISC. Sadəcə iPhone və Android telefonlarındaki (RISC arxitekturası) ARM çipləri bu kütləni təmin edir. İntelin Pentium çipləri də P6 modelindən etibarən bir RISC nüvəsi ehtiva edir. CISC komandaları RISC-ə çevrilib qiymətləndirilir.

RISC komandalarının birbaşa programlar tərəfindən istifadə edilə bilməsi üstünlüyünü də öz bərabərində gətirir. İstərsək “out of order” problemlərinin həllini complierlərə buraxa bilərik. X86 prosessorları da problemlərini özləri həll etmək məcburiyyətində. AMDnin iddialarına görə AMD çiplərində speculative execution çip üzərindəki bir “süni intellekt” modulunun köməyi ilə edilir.

Son nəsillərdə RISC prosessorları və CISC prosessorları arasında bir mikdar “convergence” oldu. Yəni bir-birinə oxşamağa başladı. Bu səbəbdən bu ən axırıncı ARM (RISC arxitekturası) prosessorlar da Spectre boşluğuna qurban gedə bilər. Teoremdə ARM (və İnteldən fərqli bir x86 arxitekturası olan AMD) Meltdown qurbanı ola bilər, ancaq tədqiqatçılar praktikada bunu tətbiq etməyi hələ ki bacara bilməyiblər.

Gələcək üçün düşüncələr.

Belə görünür Spectre/Meltdown və oxşar problemlər RISC üçün seçilən yoldan daha asan həll edilir. Spectre/Meltdown problemi prosessorun “speculative execution” etməsi səbəbilədir. Bu “speculative execution”, “Branch Delay Slot” kimi complier tərəfindən hazırlanan kodun idarəsi altında olsaydı, problem bir complier tənzimləməsi ilə həll olardı.
Bu gedişlə daha ümumi bir krizisə doğru hərəkət edirik. Prosessorlar və asılılıq səviyyəsi artır. Dünyada bir trilyon prosessora tərəf gedirik. Elə-belə təxmini hesabla adam başına 130 prosessor. Evimizdə neçə prosessor var? Kredit kartları və telefondaki sim içərisindəki prosessorları da saymağı unutmayın. Hal-hazırda bu yazını oxuyan bir şəxsin təxminən 100ə yaxın prosessoru var. Ancaq komputerlərin artan bu gücü heç etibarlı deyil. Nə serverlər, nə də “İnternet of Things” alətləri. Əslində blockchain içərisinə gizlənmiş programlar da problemli. Nəsə birşey edilməlidir.!

Uzun illərdir “Desktop mühitində GNU Linux nə vaxt qalib olacaq?” sualı verilirdi. Olmadı. Ancaq bu mübarizə fərqində olmadığımız bir şəkildə sonlandırıldı. Desktopun əhəmiyyəti çox azaldı. Digər tərəfdən server tərəfində GNU Linux və oxşarları qalibiyyət əldə etdi. Şəxsi istifadədə cib telefonu və planşetlər desktop komputerləri kölgədə buraxdı. Sadəcə MS Windows yox, İnteldən də əl çəkildi. Zəfər qazanan tərəf Unix/GNU Linux əsaslı olan iOS və Android oldu...və ARM prosessoru ilə qazandılar. Daha da maraqlısı, ikisi də aşağı-yuxarı eyni programlama dilli mühitlər yaratdı. Android üçün Google Java-nı seçdi. Apple əvvəlcə Pascal, sonra Objective C, sonra Go. Bir məsələ də ki, istifadəçiyə tutarlı bir iş təcrübəsi təqdim edə bilmək üçün developerlərə çox məhdud programlama dili seçimi verildi.
Təəssüf ki, Google və Apple programlama dili məsələsində, şirkətlər olaraq, radikal addımlar atacaq qədər cəsarətə sahib deyillər. Di gəl ki, programlama dilləri tədqiqatı sahəsində Microsoft öndədir. Microsoft Research Avropada bir qrup tədqiqatçıya himayədarlıq edir. Tip təhlükəsizliyi baxımından C#, Javadan daha sağlam bir dil; F# və F* dillərinin oxşarları Google və Apple-dan çıxmır. Go, Dart və Swift itirilmiş fürsətlərdir.

Bəs bu təhlükəsizlik problemlərini həll edəcək yeni bir paradiqma mümkündürmü? Yəni Android ilə belə birşey oldu. Yeni prosessor tipi, yeni əməliyyat sistemi və tək dilli bir mühit.
Blockchain dünyasında etibarlı, sübuta yetirilə biləcək bir formada işləyəcək programlara ehtiyac var. Blockchain dünyasında bu ehtiyacı aradan qaldırmaq üçün Simplicity, Obsidian və F* kimi dillər tövsiyə edilir. Ümumi olaraq funksional, təcrübəli şəkildə statically typed və bəzən Turing incomplete. Turing incomplete, finitistic dillərdə halting problemi həll edilə bilinir. Programların tutarlılığı da sübuta yetirilə bilinər.

Blockchain dünyasında bu yeni dillər ən təməl komputer elmləri teoreminə qayıdırlar. Lambda calculus, simple typed lambda calculus, SKI combinators bu dillər altında yatır.
Bu problemləri kökdən həll edəsiyiksə, programlama məsələsini təkrar nəzərdən keçirmək lazımdır və avadanlıq program əlaqəsi burada mühim rol oynayacaq. RISC hərəkatı ilə bu məsələ kiçik ölçüdə olsa da həll edilmişdi. Program avadanlıq əlaqəsində mühim dəyişikliklər olmuşdu.
RISC-in zəfəri icadından etiabrən 25 il çəkdi. Komputer dünyamız yeni texnologiyalar mövzusunda o qədər kobud və muhafizəkardır ki, sürətli inkişaflar gözləmək çətin məsələdir. Yoxsa ki patchlara davam edəcəyik və dünyamız get-gedə pozulan sistemlər sayəsində daha təhlükəli olacaq.

Chris Stephenson.

Mənbə: Arka Kapı Magazine


blog comments powered by Disqus