Güvenli bir programlama dili nedir?

Güvenli programlama dilleri (PL) popülerlik kazanıyor. Güvenli PL'nin resmi tanımının ne olduğunu merak ediyorum . Örneğin, C güvenli değil ancak Java güvenlidir. “Güvenli” özelliğinin PL'nin kendisinden ziyade bir PL uygulamasına uygulanması gerektiğinden şüpheleniyorum. Eğer öyleyse, güvenli PL uygulamasının bir tanımını tartışalım. Bu fikri biçimlendirme girişimlerim tuhaf bir sonuca yol açtı, bu yüzden başka görüşler duymak istiyorum. Lütfen, her PL'nin güvensiz komutları olduğunu söyleme. Her zaman güvenli bir alt küme alabiliriz.

Bir anlamda bir dili “güvenli” olarak adlandırdığımızda , bu resmen, dilde iyi biçimlendirilmiş bir programın tehlikeli olmadığını düşündüğümüz bir şey yapamayacağına dair bir kanıt olduğu anlamına gelir. “Güvenli” kelimesi aynı zamanda daha az resmi olarak kullanılır, ancak buradaki insanların sorunuzu ne anlama geldiğini anladığı budur. “Güvenli” bir dilin sahip olmasını istediğimiz birçok özellik tanımı var.

Birkaç önemli olanlar:

• Andrew Wright ve Matthias Felleisen'in birçok yerde (Vikipedi dahil olmak üzere) kabul edilen bir “tip güvenliği” tanımı olarak belirtilen “sağlamlık” tanımı ve 1994'te bir ML alt kümesinin karşıladığını gösteren kanıtlar.

• Michael Hicks burada “hafıza güvenliği” nin çeşitli tanımlarını listeler . Bazıları, oluşamayan hata türlerinin listesidir ve bazıları işaretçilere yetenek olarak bakılmasını temel alır. Java unsafe, bir çöp toplayıcısının tüm tahsisleri ve serbest bırakmaları yönetmesini sağlayarak (açıkça işaretlenmiş bir özelliği kullanmadığınız sürece) bu hataların hiçbirinin mümkün olmadığını garanti eder . Rust, aynı garantiyi (yine, açıkça işaretlenmediyseniz unsafe), en fazla bir kez kullanılmadan önce sahip olunması veya ödünç alınması gereken bir değişken gerektiren afin tip sistemiyle yapar.

• Benzer şekilde, güvenli iş parçacığı kodu genellikle, veri yarışları ve kilitlenmeler dahil olmak üzere, iş parçacığı ve paylaşılan bellek içeren belirli türde hataları gösteremeyen kod olarak tanımlanır. Bu özellikler genellikle dil düzeyinde uygulanır: Rust, veri sisteminde kendi türlerinde oluşmayacağını garanti eder; C ++, std::shared_ptrakıllı işaretçilerinin birden çok iş parçacığındaki aynı nesnelere işaret etmesini, bir nesneyi zamanından önce silmeyeceğini veya son başvuruda silme işleminde başarısız olacağını garanti eder. tahrip edildiğinde, C ve C ++ ek atomicolarak, dilin içine yerleştirilmiş değişkenlere sahiptir , doğru kullanılırsa, belirli türdeki bellek tutarlılıklarını uygulamak için atomik işlemlerin garantisi vardır. MPI, işlemler arası iletişimi açık iletilerle sınırlandırır ve OpenMP, farklı iş parçacıklarından değişkenlere erişimin güvenli olmasını sağlamak için sözdizimine sahiptir.

• Hafızanın asla sızdırmayacağı özelliğe genellikle alan güvenliği olarak adlandırılır. Otomatik çöp toplama bunu sağlayan bir dil özelliğidir.

• Birçok dilde operasyonlarının iyi tanımlanmış sonuçları olacağına ve programlarının iyi davranacağına dair bir garanti vardır. Supercat, yukarıdakilerin bir örneğini verirken, C bunu imzasız aritmetik (güvenli bir şekilde sarılması garantilidir) için yapar, ancak aritmetik imzalı değil (taşmanın keyfi hatalara neden olmasına izin verilir, çünkü C, aritmetik olarak imzalandığında çılgınca farklı şeyleri yapan CPU'ları desteklemesi gerekir) taşması)) ama sonra dil bazen sessizce imzasız miktarları imzalı olanlara dönüştürür.

• İşlevsel diller, iyi biçimlendirilmiş herhangi bir programın, örneğin saf işlevlerin yan etkilere neden olamayacağına dair garanti vermesi gereken çok sayıda değişmeze sahiptir. Bunlar “güvenli” olarak tanımlanabilir veya olmayabilir.

• SPARK veya OCaml gibi bazı diller, program doğruluğunu kanıtlamayı kolaylaştırmak için tasarlanmıştır. Bu, böceklerden "güvenli" olarak tanımlanabilir veya olmayabilir.

• Bir sistemin resmi bir güvenlik modelini ihlal edemediğinin ispatı (bu nedenle, “Muhtemelen güvenli olan herhangi bir sistem muhtemelen değildir”).

"Güvenli programlama dili" nin resmi bir tanımı yoktur; Bu gayri resmi bir kavramdır. Aksine, güvenlik sağladığı iddia edilen diller genellikle ne tür bir güvenlik talep edildiğine / garanti edildiğine / sağlandığına dair kesin bir resmi beyan sağlar. Örneğin, dil, tip güvenliği, bellek güvenliğini veya benzeri bir başka garanti sağlayabilir.

Ellerinizi Benjamin Pierce'in Türlerinin ve Programlama Dillerinin bir kopyasına götürebilirseniz , girişte, "güvenli dil" terimindeki çeşitli bakış açıları hakkında iyi bir bakış açısı vardır.

İlginç bulabileceğiniz terimin önerdiği yorumlardan biri şudur:

“Güvenli bir dil, programcının el kitabında tamamen tanımlanmıştır.” Dilin tanımının, programdaki dilde her programın davranışını tahmin etmek için anlaması gereken şeyler kümesi olmasını sağlayın. Öyleyse, C gibi bir dil için el kitabı bir tanım oluşturmaz, çünkü bazı programların (örn. Denetlenmeyen diziye erişim veya işaretçi aritmetik içerenler gibi) davranışı, belirli bir C derleyicisinin bellekteki yapıları nasıl ortaya koyduğunun ayrıntılarını bilmeden tahmin edilemez. , vb. ve aynı program farklı derleyiciler tarafından yürütüldüğünde oldukça farklı davranışlara sahip olabilir.

Bu nedenle, bir programlama dili uygulamasına atıfta bulunmak için "güvensiz" terimini kullanmakta tereddütlü olurdum. Bir dilde tanımsız bir terim, farklı uygulamalarda farklı davranışlar ortaya koyarsa, uygulamalardan biri daha fazla beklenebilecek bir davranış olabilir, ancak ben bunu "güvenli" olarak adlandırmazdım.

Güvenli ikili değil, bir sürekliliktir .

Gayri resmi olarak konuşursak, güvenlik, en sık bahsedilen 2 olan böceklere muhalefet anlamına gelir:

• Bellek Güvenliği: dil ve uygulaması, kullanıldıktan sonra ücretsiz, çift ücretsiz, sınırsız erişim gibi çeşitli bellekle ilgili hataları ...
• Tip Güvenliği: dil ve uygulaması, denetlenmeyen yayınlar gibi türle ilgili çeşitli hataları önler ...

Bunlar, dillerin önlediği tek hata sınıfı değil , veri yarışı özgürlüğü veya kilitlenme özgürlüğü daha çok arzu edilir, doğruluk kanıtları oldukça tatlıdır, vb ...

Basitçe yanlış programlar nadiren “güvensiz” olarak kabul edilir (ancak buggy) ve güvenlik terimi genellikle bir program hakkında sebep yapma yeteneğimizi etkileyen garantiler için ayrılmıştır . Dolayısıyla, Tanımlanmamış Davranışı olan C, C ++ veya Go güvensizdir.

Ve elbette, geliştiricinin dil garantilerini sağlamaktan sorumlu olduğu ve derleyicinin "hands-off" modunda olduğu alanları bilerek belirten güvenli olmayan altkümeleri (Java, Rust, ...) olan diller vardır. Pragmatik bir tanım olan bu kaçış hattına rağmen diller hala güvenli olarak adlandırılmaktadır .

DW'nin cevabına katılmıyorum, ancak sanırım "güvenli" nin bir kısmını değersiz bırakıyor.

Belirtildiği gibi, teşvik edilen çoklu güvenlik türleri vardır. Neden birden fazla kavram olduğunu anlamanın iyi olduğuna inanıyorum. Her bir kavram, programların özellikle belirli bir sınıftan muzdarip olduğu ve dil programcının bunu yapmasını engellediği takdirde programcıların bu tür bir hata yapamayacağı düşüncesiyle ilişkilidir.

Bu nedenle, bu farklı kavramların farklı böcek sınıflarına sahip olduğu ve bu sınıfların karşılıklı olarak dışlanmadığı ve bu sınıfların tüm böcek biçimlerini kapsamaz olduğu not edilmelidir. Sadece DW'nun 2 örneğini almak için, belirli bir hafıza konumunun belirli bir nesneyi tutup tutmadığı sorusu hem tür güvenliği hem de bellek güvenliği konusudur.

“Güvenli diller” hakkında bir başka eleştiri, bazı yapıları yasaklamanın tehlikeli olduğu düşünülen gözlemden sonra, programcıya alternatifler getirme ihtiyacı doğurmaktadır. Ampirik olarak, güvenlik iyi kütüphaneler tarafından daha iyi sağlanır. Sahada test edilmiş olan kodu kullanmak sizi yeni hatalardan kurtarır.

C ve Java arasındaki temel bir fark, eğer bir Java'nın kolayca tanımlanabilen bazı özelliklerinden (örneğin Unsafeisim alanındakiler) kaçınılması halinde , "hatalı" olanlar da dahil olmak üzere - yapılabilecek her türlü eylemin sınırlı bir olası sonuç aralığına sahip olmasıdır. . Bu, Java’da yapılabilecekleri sınırlandırsa da - en azından Unsafead alanını kullanmadan , aynı zamanda hatalı bir programın veya daha da önemlisi - doğru şekilde işleyebilecek bir programın neden olabileceği hasarı sınırlandırmayı da mümkün kılar. geçerli dosyalar ancak hatalı dosyalara karşı özellikle korunmuyor.

Geleneksel olarak, C derleyicileri "normal" durumlarda birçok çevre örneğini "çevreye özgü bir şekilde" işleme koyarken, standart tanımlı biçimde birçok eylemi işlerdi. Biri, sayısal taşma meydana gelirse ve CPU'nun ateş almasından kaçınmak istiyorsa, kısa devre yapan ve yangın çıkaran bir CPU kullanıyorsa, sayısal taşma olmaması için kod yazması gerekir. Bununla birlikte, eğer biri ikişeyi tamamlayıcı şekilde mükemmel şekilde mutlu bir şekilde kesecek bir CPU kullanıyorsa, böyle bir kesmenin kabul edilebilir bir davranışa yol açacağı durumlarda taşmalardan kaçınmak zorunda kalmazsınız.

Modern C, işleri bir adım öteye götürür: biri, Standart'ın hiçbir şart getirmediği sayısal taşma gibi bir davranışı doğal olarak tanımlayan bir platform hedeflese bile, bir programın bir bölümünde taşma, programın diğer bölümlerinin davranışını etkileyebilir. Program keyfi zaman ve nedensellik yasalarına bağlı değildir. Örneğin, şöyle bir şey düşünün:

 uint32_t test(uint16_t x)
 {
   if (x < 50000) foo(x);
   return x*x; // Note x will promote to "int" if that type is >16 bits.
 }

Yukarıdaki gibi bir şey verilen "modern" bir C derleyicisi, x * x'in hesaplanması eğer x 46340'tan büyükse taşması nedeniyle, koşulsuz olarak "foo" çağrısını yapabilir. Bir programın, x'in aralık dışı olması durumunda anormal şekilde sonlandırılması veya fonksiyonun bu gibi durumlarda herhangi bir değer döndürmesi kabul edilebilir olsa bile, aralık dışı x ile foo () işlevinin çok daha fazla zarara neden olabileceğini unutmayın. bu olasılıklardan herhangi biri. Geleneksel C, programlayıcı ve temel platformun sağladıkları ötesinde herhangi bir güvenlik donanımı sağlamaz, ancak güvenlik tertibatının beklenmeyen durumlardan gelen hasarı sınırlamasını sağlar. Modern C, her şeyi kontrol altında tutmada% 100 etkili olmayan güvenlik donanımlarını atlar.

Bir dilde birkaç doğruluk katmanı vardır. Artan soyutlama sırasına göre:

• Çok az program hatasızdır (yalnızca doğruluğu kanıtlanabilen programlardır). Diğerleri, hata önlemenin bu nedenle en somut güvenlik yönü olduğunu belirtmişlerdir . Java ve .net gibi sanal bir makinede çalışan diller bu açıdan genellikle daha güvenlidir: Program hataları normal olarak algılanır ve belirli bir şekilde ele alınır. ¹

• Bir sonraki aşamada, çalışma zamanında değil derleme zamanında tespit edilen hatalar dili daha güvenli hale getirir. Sözdizimsel olarak doğru bir program mümkün olduğu kadar anlamsal olarak da doğru olmalıdır. Elbette, derleyici büyük resmi bilemez, bu yüzden detay seviyesi ile ilgilidir. Güçlü ve etkileyici veri türleri, bu düzeyde güvenliğin bir yönüdür. Bir dilin belirli hatalar yapmayı zorlaştırması gerektiğini söyleyebilir(yazım hataları, sınır dışı erişim, başlatılmamış değişkenler vb.). Uzunluk bilgisi taşıyan diziler gibi çalışma zamanı tipi bilgileri hatalardan kaçınır. Ada 83'ü kolejde programladım ve derleyici bir Ada programının tipik olarak karşılık gelen C programından daha az hata derecesi içerdiğini tespit ettim. Sadece Ada'nın açıkça dönüşüm olmadan atanamayan tamsayı tiplerini kullanıcı tarafından tanımlanabilme yeteneğini kullanın: Bütün uzay gemileri düştü, çünkü ayakları ve sayaçları birbirine karıştı, ki bunlardan biri Ada ile önemsizce kaçınabilirdi.

• Bir sonraki aşamada, dil, kazan kodunu önlemek için araçlar sağlamalıdır. Kendi konteynırlarınızı veya sıralamanızı veya birleştirme işlemlerini yazmanız gerekiyorsa veya kendi cihazınızı yazmanız gerekiyorsa string::trim(), hata yaparsınız. Soyutlama seviyesi yükseldiğinden, bu kriterler dilin standart kütüphanesinin yanı sıra uygun dili de içerir.

• Bu gün dilin, dil düzeyinde eşzamanlı programlama için araçlar sağlaması gerekir. Eşzamanlılık, dil desteği olmadan doğru şekilde yapmak doğru değildir ve belki de imkansızdır.

• Dil modülerleştirme ve işbirliği için araçlar sağlamalıdır. Yukarıdaki güçlü, ayrıntılı, kullanıcı tanımlı türler etkileyici API'ler oluşturmanıza yardımcı olur.

Biraz dikey olarak, dil tanımının anlaşılabilir olması gerekir; dil ve kütüphaneler iyi belgelenmelidir. Kötü veya eksik belgeler kötü ve yanlış programlara yol açar.

Lütfen, her PL'nin güvensiz komutları olduğunu söyleme. Her zaman güvenli bir alt küme alabiliriz.

Tanıdığım her dilin çalıştırılabilecek (derlenebilecek) yasadışı programlar yazma yöntemleri var. Ve bildiğim her dilin güvenli bir altkümesi var. Peki, sorunun gerçekten ne?

Güvenlik çok boyutlu ve özneldir.

Bazı dillerin "güvensiz" olan birçok işlemi vardır. Diğerleri daha az bu tür işlemlere sahiptir. Bazı dillerde, bir şeyi yapmanın varsayılan yolu doğal olarak güvensizdir. Diğerlerinde, varsayılan yol güvenlidir. Bazı dillerde, açık bir "güvensiz" altkümesi vardır. Diğer dillerde ise böyle bir alt küme yoktur.

Bazı dillerde, "güvenlik" yalnızca bellek güvenliğine atıfta bulunur; standart kütüphane ve / veya bellek erişim ihlallerinin zor veya imkansız olduğu çalışma zamanı. Diğer dillerde, "güvenlik" açıkça diş güvenliği içerir. Diğer dillerde, "güvenlik", bir programın çökmeyeceği garantisini ifade eder (yakalanmamış istisnalara izin vermemeyi gerektiren bir şart). Son olarak, birçok dilde "güvenlik", tip emniyetini ifade eder - tip sisteminin belirli şekillerde tutarlı olması durumunda, "ses" olduğu söylenir (bu arada, Java ve C #, tamamen ses tipi sistemlere sahip değildir).

Ve bazı dillerde, "emniyet" in tüm farklı anlamları, tip emniyetinin altkümeleri olarak kabul edilir (örn. Rust ve Pony, tip sisteminin özelliklerinden iplik güvenliğini sağlar).

Bu cevap biraz daha geniş. Güvenli ve emniyet kelimeleri, son yıllarda, İngilizce konuşan toplumun politik yönelimli bazı bölümleri tarafından, ortak kullanımlarının neredeyse hiçbir tanımı olmayacak şekilde kesildi. Bununla birlikte, teknik konular için hala “güvenlik” ve “güvenli” olarak tanımlamaya devam ediyorum: bir şeyin istemeden kullanılmasını önleyen veya yanlışlıkla kullanımını önemli ölçüde zorlaştıran bir cihaz ve böyle bir cihazın koruması altında olma durumu .
Bu yüzden güvenli bir dilin belirli bir sınıf sınıfı sınırlayacak bir cihazı vardır. Tabii ki, bazı durumlarda bazı durumlarda uygunsuzluk ve hatta yetersizlik söz konusudur ve bu, "güvensiz" dillerin hatalara yol açacağı anlamına gelmez. örn. Çatallarımda güvenlik mantarları yok ve uzun yıllar boyunca, yemek yerken gözümü bıçaklamaktan kaçınmak için çaba sarfediyorum. Mantarların kullanılmasıyla harcanacak harcamadan kesinlikle daha az çaba harcandı. Bu yüzden Güvenlik, yargılanması gereken bir bedelle gelir. (mantar çatal Steve Martin karakterinin bir referansıdır)