Sahipli bir aygıt sürücüsü yalnızca ikili kodda yayımlanan kapalı kaynak kodlu bir aygıt sürücüsüdür. Özgür ve açık kaynak yazılımlar bağlamında kapalı kaynak kodlu bir aygıt sürücüsü; blob veya ikili blob olarak adlandırılır. Terim genellikle açık kaynak bir işletim sisteminin ekirdeğine yüklenen kapalı kaynak bir çekirdek modülünü belirtir ve bazen sistem üretici yazılımı görüntüleri, mikro kod güncellemeleri veya kullanıcı alanı programları gibi çekirdeğin dışında çalışan koda da uygulanır. Blob terimi ilk önce veri tabanı yönetim sistemlerinde tek bir varlık olarak depolanan ikili veri koleksiyonunu tanımlamak için kullanılmıştır.

Bilgisayar donanımı satıcıları ürünleri için eksiksiz teknik belgeler sağladığında işletim sistemi geliştiricileri işletim sistemi çekirdeğine dâhil edilecek donanım aygıtı sürücülerini yazabilir. Ancak Nvidia gibi bazı satıcılar; ürünlerinin bir kısmı için tam bir dokümantasyon sağlamaz ve bunun yerine sadece ikili sürücüler sunar. Bu uygulama en çok hızlandırılmış grafik sürücüleri, kablosuz ağ aygıtları ve donanım RAID denetleyicileri için yaygındır. En önemlisi ikili blob’lar, neredeyse her zaman kutudan çıkan standart yardımcı programlar (ifconfig gibi) aracılığıyla yapılandırılabilen kablosuz olmayan ağ arabirimi denetleyicileri için çok nadirdir: OpenBSD’den Theo de Raadt, bunu tek bir FreeBSD geliştiricisi tarafından yapılan işe atfediyor.

Açık Kaynak İşletim Sistemleri

Bazı FSF onaylı projeler özgür bir işletim sistemi sağlamaya çalışır ve aygıt sürücüleri için donanım ya da kaynak kodu ile ilgili dokümantasyon olmadığında tüm ikili blob’ları kaldırır: Bu tür projeler arasında FSFLA, Parabola, Devuan, Trisquel ve LibreCMC’den Linux-libre çekirdek paketleri yer almaktadır. Bununla birlikte açık kaynak projelerin büyük çoğunluğu, sadece sahipli ikili aygıt sürücüleri (blob’lar) ve yalnızca ikili firmware (blob’lar olarak kabul edilmez) arasında ayrım yaparak bazı sahipli aygıt yazılımlarının çekirdeklerinin bir parçası olarak serbestçe dağıtılmasını sağlar ve bazı çekirdek katkı paydaşlarının uyuşmazlığına göre haricî olarak dağıtılan sahipli aygıt sürücülerinin kullanımını da destekleyerek bu tür özel sürücüler ve kullanıcı alanı bileşenlerinin kendi sistemleri ile çalışabilmeleri için dâhilî uyumluluk arayüzleri sağlar. Bu politikayı izleyen projeler arasında Linux çekirdeği, NetBSD, FreeBSD, DragonFly BSD ve çoğu Linux dağıtımı bulunur. Bu projelerden bazıları; sistemi sahipli firmware olmadan kurmak için seçenekler sunar, böylece talep üzerine kaynak dışı mikro kodlar hariç tutulur.

OpenBSD projesi; yalnızca herhangi bir ikili aygıt sürücüsünü kaynak ağacına kabul etmekle kalmayıp aynı zamanda sadece tespit edilemeyen veya onarılamaz güvenlik kusurları potansiyelini değil, aynı zamanda yazılımının açıklığına ve özgürlüğüne yönelik gaspı da gerekçe göstererek platformundaki herhangi bir üçüncü taraf sahipli aygıt sürücüsü bileşenini resmî olarak desteklemiyor. Özgür Yazılım Vakfı (FSF [Free Software Foundation]) aktif olarak ikili blob’lara karşı kampanya yürütüyor. Ayrıca FSF; OpenBSD’nin politikasını kafa karıştırıcı bir şekilde ele aldığını, BSD topluluğundaki “blob’lar”ın yalnızca özgür olmayan sürücüleri gördüğü şeyleri ifade ettiğini ve sahipli firmware ve kaynak kodlu olmayan mikro kod için geçerli olmadığından bahseder. Linux çekirdeğinden firmware, özgür olmayan paketleri Debian Social Contract’a göre açıkça işaretler ve ayırır. Debian 6.0’dan itibaren bu blob’lar giderildi.

OpenBSD için proje lideri Theo de Raadt, yalnızca mikro kod firmware için dağıtım hakkı isteme politikasını savunuyor. “Bir kez dağıtıldılar… en azından aygıt çalışıyor.” Alternatifinin küçük projenin üyeleri için özgür firmware’nin kendisini birçok yonga setinin çevirme dilinde kodlayabilmesi olduğunu ima ederek “bizi daha fazla işle doldurmadığını” iddia ediyor. Buna rağmen firmware olmadan çalışan ve piyasaya daha yavaş ancak daha olgun olarak tanımladığı Asya tasarımlarından sıcak bir şekilde konuşan yonga setlerini tercih ediyor.

Linux çekirdeği geliştirme topluluğunda Linus Torvalds, sadece ikili sistem modülleri konusunda güçlü açıklamalar yaptı: “Ellerimi sadece ikili bir modüle bağlamayı düşünmeyi bile reddediyorum” diyerek şöyle devam etti: “İnsanların bunu ne zaman bilmelerini istiyorum: Sadece ikili modül kullanıyorlar, bu ONLARIN problemi.” 2008’de 176 Linux çekirdeği geliştiricisi, “Aşağıda imzası olan Linux çekirdek geliştiricileri olarak herhangi bir kapalı kaynak kodlu Linux çekirdek modülünü veya sürücüsünün zararlı ve istenmeyen olduğunu düşünüyoruz… Onları defalarca Linux kullanıcıları, işletmeleri ve Linux ekosistemi için zararlı bulduk.” diyen bir Position Statement on Linux Kernel Modules‘i imzaladı. Linux çekirdeği bakımcısı Greg Kroah-Hartman, GNU Genel Kamu Lisansı lisanslı Linux çekirdeği için kapalı kaynak modüllerini yeniden dağıtmanın yasal olmadığını belirtti.

Ancak Linux çekirdeği çeşitli aygıt sürücülerinin ihtiyaç duyduğu kapalı kaynak kodlu firmware içerir. Linux çekirdeğinin bir bakımıcısı olan ve Linux çekirdeğinin bir kaynağı olan ve kaynak kodsuz mikro kod dâhil tüm ikili blob’u kaldırmaya çalışan Alexandre Oliva, 2011’de şunu yazdı: “Linux, 1996’dan beri Torvalds’ın 1991’den beri yayımladığı Linux dağıtımlarında ilk Özgür Olmayan Yazılım parçalarını kabul ettiği zaman Özgür Yazılım olmamıştır. Bu yıllar boyunca bu çekirdeğin miktarı 14 kat arttı. Linux sürücülerinin ihtiyaç duyduğu özgür olmayan olmayan firmware, endişe verici bir 83 katsayı olarak büyüdü.”

Android işletim sistemini çalıştıran mobil aygıtların sürücülerinin çoğu ikili olarak gönderilir ve Linux çekirdeğinin belirli bir sürümüne bağlanır. Bu, bir çekirdek sürümünü yükseltmeyi çok zorlaştırır çünkü tersine mühendislik gerektirebilir, sahipli aygıt sürücülerini özgür yazılım olarak yeniden uygulama; örtü oluşturma ve hata ayıklama, ikili düzeltme eki veya bu adımların bir birleşimidir; bunların hepsi eski aygıtların asla en son Android sürümünü alamayacaklarını gösterir.

Sorunlar

İkili blob’ların sorunlu olmasının birkaç nedeni vardır.

Birincisi; kesin operasyonları bilinemez ve kaynak kodu denetlenerek hatalar tespit edilemez: Hatalar genellikle bir sistem beklenmedik bir şekilde çalışmaya başladığında titizlikle soruşturmayla teşhis edilir. Bu tür tespit edilmeyen hatalar; kullanıcıları ve sistemleri sessizce güvenlik tehlikelerine maruz bırakabilir. Bu nedenle sürücünün amacına uygunluğu kontrol edilemez ve bir hata bulunsa bile düzeltmenin kolay bir yolu yoktur.

İkincisi; kaynak kodu mevcut olmadığından sürücü kullanıcıları tarafından kolayca geliştirilemez, orijinal olarak desteklenmeyen yapılara aktarılamaz, donanımın küçük değişkenleri için çalışacak şekilde uyarlanamaz veya değiştirilen API ve mimariye sahip yeni çekirdeklerde uygulanabilir olacak şekilde güncellenemez.

Üçüncüsü; bu yazılımı kullanmak kullanıcıları satıcıya veya üçüncü taraflara arka kapı, casus yazılım veya kötü amaçlı kodları blob’a koymamaları konusunda güvenmeye zorlar. Ayrıca donanım satıcısı; belirli bir işletim sistemini desteklememeye, herhangi bir zamanda sürücü bakımını bırakmaya veya şirketin iş dışında kalması durumunda sürücüyü tamamen desteksiz bırakmaya karar verebilir.

Son olarak ikili blob’lar; özgür yazılım ideallerine inanan topluluğun bir kısmı sahipli yazılımı reddederek yalnızca teknik nedenlerden dolayı açık kaynağı arzulayan, genellikle “çalıştığı sürece” ikili blob’lara karşı güçlü bir muhalefetten yoksun görnen bir çizgi çiziyor gibi görünebilir. Bu parçalanma ve gittikçe artan sayıda sahipli bileşenlerin Linux’a kabul edilmesi, topluluğun üreticilerin ikili dokümanları için dokümantasyon sağlamayı giderek daha fazla reddetme eğilimine direnme yeteneğini zayıflattığı görülmektedir.

Örtüler İle Kullanın

Bir örtü, bir işletim sisteminin başka bir işletim sistemi için yazılmış bir ikili sahipli aygıt sürücüsü kullanmasına izin veren bir yazılımdır. Örtü örnekleri Linux için NdisWrapper ve FreeBSD ve NetBSD için Project Evil’dir. Bu örtüler, bu işletim sistemlerinin Microsoft’un NDIS API’sini uygulayarak Microsoft Windows için yazılmış ağ sürücülerini kullanmasına izin verir.

Başka bir örnek de uyumluluk katmanları sağlamaktır; böylece donanıma hizmet vermek için yabancı yardımcı programlar kullanılabilir. Örnekler, FreeBSD’deki bazı RAID denetleyici sürücülerini içerir; burada sistem yöneticisi FreeBSD’de Linux uyumluluk katmanını etkinleştirmek ve bağımsız olarak donanımları izlemek ve hizmet vermek için Linux’a sahipli ikili blob’ları doğrudan donanım üreticisinden temin etmek zorunda kalır. 2005 dolaylarnda bu durum OpenBSD’den her ikisi de daha sonra NetBSD’ye giden yolunu da bulduğu RAID izleme için alternatif bir çözüm olarak bio(4), bioctl ve sensor_drive konseptlerini yaratma ve popüler hâle getirmeye teşvik etti.

Aygıt Firmware’si

Firmware; bazı donanıma eşlik eden yerleşik mikro denetleyiciler tarafından istenen yazılımdır, genellikle ikili bir blob olarak kabul edilmez. Birçok aygıtta firmware; kalıcı dâhilî flash bellekte saklanır ancak maliyetleri azaltmak ve yükseltmeleri kolaylaştırmak için bazı aygıtlar yalnızca statik RAM içerir ve ana bilgisayar işletim sisteminin her bağlandığında firmware’yi yüklemesini gerektirir (özellikle USB aygıtları). Her ne kadar firmware bu nedenle işletim sistemi sürücüsünde bulunur, yalnızca aygıta kopyalanır ve aygıt tarafından her zaman önceden kaydedilmiş olsa bile DMA saldırısı ile zaten mümkün olan durumlara kıyasla ekstra güvenlik hataları hakkındaki endişeleri ortadan kaldırır. OpenBSD projesi ikili firmware / mikro kod görüntülerini kabul eder ve lisans izin verirse bu görüntüleri yeniden dağıtacaktır; satıcı tarafından ücretsiz ve koşulsuz yeniden dağıtıma izin verilmiyorsa bu görüntüleri elde etmek için makine yönergeleri bağlantı noktaları ağacında (bu, bazı yerleşik kablosuz aygıtların [örneğin; Intel Wireless] ilk kurulum sırasında kullanılmasını engelleyen) sağlanabilir.

BIOS ve UEFI

Bir önyükleyici olarak çalışan ve eski gerçek mod uygulamalarını destekleyen BIOS, pek çok IBM uyumlu bilgisayarın çok önemli bir bileşenidir. BIOS her zaman 16 bittir, genellikle ağ işlevlerine sahiptir ve bir güvenlik arka kapısı olabilir. 1990’ların sonunda eski BIOS’u modüler bir sürücü modeliyle modern bir arayüze taşımak amacıyla EFI (Extensible Firmware Interface) üzerinde çalışmaya başladı. EFI kapalı kaynak kodludur ve sonunda sektörün önde gelen donanım üreticileri tarafından UEFI (Unified Extensible Firmware Interface) olarak kabul edildi. EDK (EFI Development Kit); EFI ürün yazılımı geliştirme projelerine yardımcı olmak için geliştirilmiştir.

Ayrıca 1990’ların sonlarında coreboot projesi, eski BIOS’a sıfırdan alternatif bir açık kaynak yaratmaya başladı. Çekirdek geliştirici topluluğu Stefan Reinauer’in etrafında örgütlenir ve yazılım geliştiricileri tarafından taahhüt haklarına sahiptir. Kapalı kaynak kodlu ikili firmware’ye rağmen x86 mimarisinin merkezinde yer alan coreboot, kullanıcılara temel düzeyde donanım desteği sağlamak için gerekli olan birkaç sahipli ikili dosyayı içeriyor. BIOS ve UEFI’ye tamamen bir açk kaynak alternatifi, Özgür Yazılım Vakfı (FSF [Free Software Foundation]) tarafından desteklenen libreboot’tur.

Ayrıca Bakınız

Free and open-source software portal

References