Güvenilir özgür/açık kaynak Linux destekli 64 bit RISC-V self-hosting bilgisayar

 (contrib.andrew.cmu.edu)
1 puan yazan GN⁺ 2024-05-20 | 1 yorum | WhatsApp'ta paylaş
  • Amaç, tüm çalışma biçimi açık HDL ve yazılım kaynakları üzerinden izlenebilen ve bu sistem üzerinde araç zincirine kadar yeniden derlenip çalıştırılabilen bir self-hosting özgür/açık kaynak yığını oluşturmak
  • Kendi ASIC'inizi doğrudan üretemediğiniz için donanım FPGA üzerinde kuruluyor ve bitstream üretimi ile programlamanın da özgür/açık kaynak araçlarla yapılması gerekiyor
  • FPGA yaklaşımının, dökümhanenin gerçek kullanım alanını ve hassas bit yerleşimlerini anlamasını zorlaştırarak üretim aşaması saldırılarını DoS düzeyiyle sınırlayabileceği düşünülüyor
  • Düzenli ızgara yapısına sahip FPGA'larda kimyasal söküm ve TEM görüntüleme gibi yıkıcı görsel incelemeler, özel ASIC'lere kıyasla daha uygulanabilir kabul ediliyor
  • Geriye kalan güven sorunu ise HDL, yazılım, derleyici ve araç zincirinin tamamını açık kaynaktan derlenebilir hale getirerek doğrulama kapsamını denetlenebilir kaynakla sınırlamak

Güvenilir bir bilgisayar için gerekenler

  • Hedef, en alttan başlayarak özgür/açık kaynak bir bilgisayar kurmak ve donanım ile yazılımın tüm davranışını açık HDL ve yazılım kaynaklarıyla açıklanabilir hale getirmek
  • Tüm sistemi oluşturan derleyici ve ilgili araç zinciri de özgür/açık kaynak olmalı ve söz konusu bilgisayar üzerinde derlenip çalıştırılabilmeli
  • Sonuç olarak gereken şey, self-hosting özgür/açık kaynak donanım+yazılım yığını
  • Silikon dökümhanesine sahip olunmadığı veya onu kontrol etme imkanı bulunmadığı için donanım bileşenleri FPGA üzerinde gerçekleştiriliyor
  • FPGA programlama ve bitstream üretiminin de özgür/açık kaynak araçlarla yapılması, güven modelinin korunması için gerekli

FPGA'nın sağladığı güvenilirlik ödünleşimi

  • FPGA kullanımı, özel ASIC üretmek yerine seçilmiş gerçekçi bir ödünleşim
    • Çip dökümhanesinin FPGA'nın nerede kullanılacağını ve sözde privilege bit'lerin çip içinde nereye yerleştirileceğini bilmesi zor
    • Bu koşullarda yetki yükseltmeye yönelik donanımsal arka kapılar hafifletilebilir ve FPGA üretim aşamasında yerleştirilebilecek saldırıların DoS ile sınırlı kalacağı düşünülüyor
    • Bilgisayar tamamen durabilir, ancak normal çalışıyormuş gibi yaparken sahibine ihanet etme olasılığının daha düşük olduğu değerlendiriliyor
  • FPGA'lar, aynı bileşenlerin tekrar ettiği düzenli bir ızgara yapısına sahip olduğundan, özel ASIC'lere göre yıkıcı görsel incelemeye daha elverişli görülüyor
    • Buna kimyasal söküm ve TEM görüntüleme örnek veriliyor
  • Üretim aşamasındaki saldırı yüzeyi azaltıldıktan sonra bile kötü niyetli kaynak kodu veya araç zinciri gibi riskler sürüyor
    • Bu sorun, tüm HDL, yazılım ve araç zincirinin derlenebilir açık kaynak olmasını şart koşarak ele alınıyor

Referanslar ve uygulama deneyleri

İlgili okumalar

1 yorum

 
GN⁺ 2024-05-20
Hacker News yorumları

  • Teorik olarak FPGA içinde gizli bir CPU olabilir ve FPGA programının tamamına okuma/yazma erişimi de olabilir diye düşünüyorum
    Ayrıca aynı sistem ya da sonraki nesil için FPGA üretim hacmi artarsa, dökümhane ek bilgi edinir ve yetki bitlerinin nerede olduğunu oldukça iyi tahmin edebilir
    Daha basit bir ihtimal olarak, FPGA'ya kod yükleyip doğrudan analiz de edebilirler

    • Bugünlerde hepsi zaten böyle. Gizli de değiller
      Büyük bir FPGA satın alırsanız içinde ARM çekirdekleri olur ve bu ARM çekirdeklerinin hepsi EL3'te kullanıcının değiştiremediği opak imzalı blob'lar çalıştırır
      Bu, fabric üzerindeki bir soft core değil, ayrılmış silikondur ve Xilinx aygıtlarındaki ICAP yani Internal Configuration Access Port'a ve diğer üreticilerin eşdeğer özelliklerine de erişebilir
    • RAM'e arka kapı yerleştirmek daha kolay olur gibi geliyor
      Modern DRAM; link training, targeted refresh, on-die error correction gibi karmaşık özelliklerle dolu ve tam uygulamayı bilmesem de arka kapı gizlemek için yeterince karmaşık
      Belirli bellek erişim kalıplarını izleyip doğru kalıp algılandığında keyfi okuma/yazma yetkisi veren bir özellik eklenebilir
      Böylece JavaScript gibi güvenilmez ama sandbox içinde çalışan kodlardan yetki yükseltmede kullanılabilir ve keyfi bellek okumasıyla nereye yazılacağını da bulabileceği için CPU mimarisinden ya da işletim sisteminden bağımsız çalışabilir
      DIMM ya da çok çipli bellek modüllerinde daha az etkili olurdu ama RISC-V bilgisayarlar genelde tek DRAM çipli küçük tek kart bilgisayarlardır
    • Bu yaklaşım, kötü amaçlı bir derleyicinin kendini yayan arka kapıya sahip olduğu Thompson hack'e benziyor
      Kaynak kodda görünmez ama ikiliye kendini enjekte eder
      Thompson bunu kontrollü koşullarda göstermişti ama pratikte böyle bir arka kapının tespit edilmeden kalması için neredeyse AGI seviyesinde bir kurnazlık gerekir
      Donanım ve yazılım evrilse bile çalışmaya ve yayılmaya devam etmesi, ayrıca boyut ve çalışma süresi gibi izleri de sürekli düşük tutması gerekir
      Modern hesaplamayı bu şekilde tamamen farklı temeller üzerinde yeniden inşa etmek, bu tür arka kapıların kullanılmasını ciddi biçimde zorlaştırır ve karmaşıklaştırır
      https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_...
    • I/O'yu dinleyip bir şekilde veriyi dışarı sızdırmanın daha kolay olup olmayacağını da merak ediyorum
      Elbette büyük ölçekli kitlesel gözetim için tamamen gerçek dışı olurdu, ama bir devlet aktörü bir kuruluşun gözetimden kaçmak için bu tekniği kullandığını ve yazılım düzeninin de öngörülebilir olduğunu bilirse durum değişebilir
    • Böyle bir CPU olsa bile, FPGA üzerindeki hangi register ya da gate'in soft CPU'nun hangi bileşenini gerçekleştirdiğini anlamak son derece zor olurdu
      Yerleşim sabit değildir ve donanımsal LUT/FF ile sentezlenmiş işlevler arasında da tutarlı bir eşleme yoktur

  • Açık kaynak araç zinciriyle derlenmiş RISC-V softcore'un çalışan orangecrab FPGA'sına bir Linux shell ile giriş yapılabilmesi gerçekten şaşırtıcı
    Çok kısa süre öncesine kadar bu imkânsızdı; en fazla Xilinx PetaLinux ve onların kapalı kaynak ıvır zıvırı vardı

    • İlginç olan, orangecrab'in FPGA'sının bile şart olmaması
      Küçük bir iCE40 LP1K içine bile SERV, hatta QERV sorunsuz sığıyor
      Tam uyumlu bir RISC-V uygulamasının ne kadar küçülebilmesi gerçekten şaşırtıcı
    • Yakında topluluğu bir araya getiren bir kıvılcım olacağını düşünüyorum
      Açık donanım ve açık yazılım sonunda birlikte çalışıyor ve 10 yıl içinde çok büyük bir akıma dönüşecek

  • Benzer bir yöne gidiyor ama yol farklı
    Tasarımım VexRiscv tabanlı ve tüm donanım SpinalHDL ile yazıldı
    Karnix kartındaki SRAM 512KB ile sınırlı olduğu için henüz Linux çalıştıramıyor ama Ethernet ve HDMI var
    Grafik için 320x240x4 ve metin için 80x30x16 modlarını destekleyen, ayrıca donanım destekli yumuşak kaydırma yapabilen CGA benzeri bir video bağdaştırıcısını da HDMI arayüzü üzerinden uyguladım
    İlgilenenler için kısa README burada: https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...
    Kartın KiCAD projesi: https://github.com/Fabmicro-LLC/Karnix_ASB-254

  • Harika bir çalışma
    trusting trust saldırısına karşı yaptığım çeşitli ikili derleme (DDC) çalışmasının belirgin biçimde alıntılanmış olmasına sevindim
    DDC ile ilgileniyorsanız buraya bakın: https://dwheeler.com/trusting-trust

  • Sistemi kendi üzerinde yeniden derlemek ve bitfile'ın aynı olduğunu doğrulamak güzel
    Bunun 512MB içinde yeniden derlenebilmesi ve yaklaşık 65MHz'lik bir CPU'da “yalnızca” 4,5 saat sürmesi etkileyici
    yosys ya da vivado gibi araçları kullanma deneyimime göre bunlar genelde birkaç GB ister gibi geliyordu
    65MHz Linux çalıştırabilen bir CPU'nun 1990'ların ortasındaki Intel 486 ve ilk nesil Pentium'u hatırlattığı söylenmiş ama 50~65MHz ve 512MB birleşimi bana daha çok 1990'ların başındaki Unix iş istasyonlarını çağrıştırıyor
    RAM tarafı ise hatta daha iyi bile sayılabilir
    Referans olsun diye, lowRISC/50MHz üzerinde çift hassasiyetli linpack 4.5 Mflops veriyor

  • 2022'de benzer bir şeyi LiteX ile denedim ama Kintex-7 FPGA kullandığım için, en azından o dönemde gerçek place-and-route için Vivado gerektiğinden bu self-hosting değildi
    Yine de Linux ve Xorg çalıştıran açık gateware bir dizüstü bilgisayar ortaya çıktı; bunu Linux-on-LiteX-VexRiscV sağladı: https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.h...

  • Hindistan IIT-Madras'ın RISC-V tabanlı Shakti projesine de bakmaya değer: Open Source Processor Development Ecosystem - https://shakti.org.in/
    Wikipedia'daki genel bakış da iyi: https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)

  • Bu kişi, zamanında qemu/kvm üzerinde OS X çalıştırma ile ilgili işler yapan kişiyle aynı: https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

  • Gerçekten harika
    Bir süredir tamamen kendi kendini barındıran bir RISC-V makinesine acilen ihtiyaç olduğunu düşünüyordum
    Şu anda en büyük kısıt, yeterli yerleşik RAM'e sahip bir FPGA kartı bulmak gibi görünüyor
    Buradaki hedef kart galiba 512MB, ama FPGA toolchain'leri genelde birkaç GB kullanabildiğinizde çok daha rahat ediyor

  • Kendi kendini barındıran donanım ve yazılım fikri güzel, ama 60MHz CPU'da GCC gibi bir şeyi derlemenin acısını hayal bile edemiyorum
    Üstelik Rocket CPU Scala ile yazılmış
    Yakın zamanda RockPro64 üzerinde Gentoo kullanmayı bıraktım, çünkü derleme süreleri dayanılmazdı
    O sistem bile burada kullanılmak istenenden birkaç mertebe daha hızlı

    • Çok daha hızlı yapmak mümkün
      Bu özgür/açık kaynak çekirdeklerin önemli bir kısmı ya pek optimize edilmemiş durumda ya da ASIC hedeflenerek tasarlanmış, bu yüzden FPGA üzerinde performansları çok kötü oluyor
      İyi tasarlanmış bir çekirdeği modern bir FPGA'ya koyarsanız, böyle en alt seviye düşük güç tüketimli Lattice parçaları dışında, daha güçlü bir mikro mimariyle 250MHz üstü gayet mümkün
      Sadece ne ucuz ne de kolay, bu yüzden hobi alanında pek görünmüyor
      Ayrıca daha iyi FPGA'larda çoğu zaman özgür/açık kaynak toolchain bulunmuyor; bu da özgür yazılım ruhuyla çok uyumlu değil
      Yine de 250MHz'de bile bir softcore üzerinde Chipyard çalıştırmak sabır eğitimi olurdu
    • Eskiden gerçekten 50MHz SPARC sistemlerde iş yaptık; çevre birimleri de 10Mbps Ethernet ve yavaş SCSI sürücüler gibi çok daha yavaştı, RAM de daha az ve daha yavaştı
      Yalnız istediğiniz her şeyi derlemek bir hafta sürebilir, buna katılıyorum
      Tabii çapraz derleme diye bir seçenek de var
    • 60MHz CPU'da GCC gibi bir şeyi derlemenin nasıl bir his olduğunu hatırlayan insanlar da var
      O kadar da eski bir şey değil
    • Bir zamanlar 60MHz hızında çalışan bir bilgisayara sahip olmak hayaldi
      Kullandığım ilk bilgisayarlar yaklaşık 1MHz'de çalışıyordu
      Yavaş makinelerde derleme daha uzun sürer, ama bu tek başına büyük bir sorun değil
      Bilgisayar kararlıysa ve build script'leri doğruysa, onu günlerce ya da haftalarca çalışır halde bırakabilirsiniz
      Hayatım boyunca günler ya da haftalar süren pek çok iş çalıştırdım
      “compiling” için bkz.: https://xkcd.com/303/
      Asıl sorun debugging
      Yavaş bir sistemde debugging yaparken yineleme döngüsü uzar ve bu can sıkıcı olabilir
      Tarihsel olarak bu, adımları bölüp çeşitli noktalardan yeniden başlayabilmeyi sağlayarak, her seferinde tüm süreci tekrar etmeyi önleyecek şekilde çözüldü
      Burada da aynı yaklaşım işe yarar
      Ek olarak, daha hızlı ama daha az güvenilir bir sistemde script'leri debug edip, çalıştığı doğrulandıktan sonra onları yavaş sistemde çalıştırma seçeneği de var