Komputer self-hosting RISC-V 64-bit yang dapat dipercaya dengan dukungan Linux bebas/open source
(contrib.andrew.cmu.edu)- Tujuannya adalah membuat stack bebas/open source yang self-hosting sehingga seluruh operasinya dapat ditelusuri ke HDL yang dipublikasikan dan source software, dan bahkan toolchain dapat dibangun ulang serta dijalankan di atas sistem itu sendiri
- Karena tidak bisa memproduksi ASIC secara langsung, perangkat keras diimplementasikan di atas FPGA, dan pembuatan bitstream serta pemrogramannya juga harus ditangani dengan alat bebas/open source
- Pendekatan FPGA dianggap membuat foundry sulit mengetahui penggunaan sebenarnya dan penempatan bit sensitif yang sesungguhnya, sehingga serangan pada tahap manufaktur dapat dibatasi ke tingkat DoS
- FPGA yang memiliki struktur kisi teratur dinilai lebih realistis untuk inspeksi visual destruktif seperti pengelupasan kimia dan pencitraan TEM dibanding ASIC khusus
- Masalah kepercayaan yang tersisa adalah membuat HDL, software, compiler, dan toolchain semuanya dapat dibangun dari source terbuka, sehingga cakupan verifikasi dipersempit ke source yang dapat diaudit
Syarat untuk komputer yang dapat dipercaya
- Tujuannya adalah membangun komputer bebas/open source dari dasar, sehingga seluruh perilaku perangkat keras dan software dapat dijelaskan melalui HDL yang dipublikasikan dan source software
- Compiler dan toolchain terkait yang membangun keseluruhan sistem juga harus bebas/open source, serta harus bisa dibangun dan dijalankan di komputer tersebut
- Pada akhirnya, yang dibutuhkan adalah self-hosting stack perangkat keras + software bebas/open source
- Karena tidak memiliki atau mengendalikan silicon foundry, komponen perangkat keras diimplementasikan di atas FPGA
- Pemrograman FPGA dan pembuatan bitstream juga harus dilakukan dengan alat bebas/open source agar model kepercayaannya tetap terjaga
Kompromi kepercayaan yang diberikan FPGA
- Penggunaan FPGA adalah kompromi realistis yang dipilih alih-alih membuat ASIC khusus secara langsung
- Foundry chip sulit mengetahui FPGA itu akan digunakan untuk apa, atau di mana apa yang disebut privilege bit ditempatkan di dalam chip
- Dalam kondisi ini, hardware backdoor untuk eskalasi privilese dapat dikurangi, dan serangan yang bisa ditanam pada tahap pembuatan FPGA dianggap terbatas pada DoS
- Komputer mungkin bisa berhenti total, tetapi kecil kemungkinan ia berpura-pura berfungsi normal sambil mengkhianati pemiliknya
- FPGA memiliki struktur kisi teratur dengan komponen identik yang berulang, sehingga dianggap lebih memungkinkan untuk inspeksi visual destruktif dibanding ASIC khusus
- Contohnya adalah pengelupasan kimia dan pencitraan TEM
- Bahkan setelah mengurangi permukaan serangan pada tahap manufaktur, risiko seperti source berbahaya atau toolchain berbahaya tetap ada
- Masalah ini ditangani dengan mewajibkan semua HDL, software, dan toolchain tersedia sebagai source terbuka yang dapat dibangun
Referensi dan eksperimen implementasi
- FOSDEM 23: slide dan presentasi terbaru
- linux-on-litex-rocket: panduan build terbaru
- self-hosting demo: demo self-hosting
- CReSCT 2020 Paper, Slides, Presentation: materi presentasi terkait IEEE S&P 2020
- lowRISC project: berguna untuk memahami komponen, tetapi saat itu bergantung pada toolchain HDL tertutup dan modul IP proprietari seperti controller DRAM
- yoloRISC: demo SoC blinky berbasis RV64IMAC Rocket-Chip untuk board Lattice ECP5 5G Versa
1 komentar
Komentar Hacker News
Secara teoretis, bisa saja ada CPU tersembunyi di dalam FPGA yang juga punya akses baca/tulis ke seluruh program FPGA
Selain itu, jika volume produksi FPGA meningkat untuk sistem yang sama atau generasi berikutnya, pihak foundry bisa memperoleh informasi tambahan dan menebak dengan cukup baik di mana bit otorisasinya berada
Cara yang lebih sederhana adalah langsung memuat kode ke FPGA dan menganalisisnya sendiri
Jika Anda membeli FPGA besar, di dalamnya ada core ARM, dan semua core ARM itu menjalankan blob bertanda tangan yang opak dan tidak dapat diganti pengguna di EL3
Ini bukan soft core di atas fabric, melainkan silikon khusus, dan ia juga dapat mengakses ICAP pada perangkat Xilinx, yaitu internal configuration access port, serta fitur setara dari produsen lain
DRAM modern punya banyak fitur rumit seperti link training, targeted refresh, dan on-die error correction, dan meski implementasi persisnya tidak diketahui, kompleksitasnya sudah cukup untuk menyembunyikan backdoor
Bisa saja ditambahkan fungsi yang memantau pola akses memori tertentu lalu memberikan hak baca/tulis arbitrer saat pola yang tepat terdeteksi
Dengan begitu, ini bisa dipakai untuk eskalasi hak akses dari kode yang tidak tepercaya tetapi disandbox seperti JavaScript, dan karena pembacaan memori arbitrer bisa menemukan lokasi tempat menulis, ini juga dapat bekerja terlepas dari arsitektur CPU atau sistem operasinya
Ini mungkin kurang efektif pada DIMM atau modul memori yang terdiri dari banyak chip, tetapi komputer RISC-V biasanya adalah single-board computer kecil dengan hanya satu chip DRAM
Ia tidak tampak di source code, tetapi menyuntikkan dirinya sendiri ke dalam biner
Thompson mendemonstrasikan hal ini dalam kondisi terkontrol, tetapi secara realistis, agar backdoor semacam itu lolos dari deteksi akan dibutuhkan kecerdikan yang nyaris setingkat AGI
Ia harus terus bekerja dan menyebar meski hardware dan software berevolusi, sambil tetap menjaga jejak seperti ukuran atau waktu eksekusi tetap rendah
Membangun ulang komputasi modern sepenuhnya di atas fondasi yang berbeda seperti ini akan sangat menghambat dan mempersulit penggunaan backdoor semacam itu
https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_...
Tentu itu sepenuhnya tidak realistis untuk pengawasan massal berskala besar, tetapi ceritanya bisa berbeda jika aktor negara tahu bahwa suatu organisasi memakai teknik ini untuk menghindari pengawasan dan konfigurasi softwarenya dapat diprediksi
Penempatannya tidak tetap, dan juga tidak ada pemetaan yang konsisten antara LUT/FF hardware dan fungsi hasil sintesis
Sungguh menakjubkan bahwa kita bisa login ke shell Linux pada orangecrab FPGA yang menjalankan softcore RISC-V yang dibangun dengan toolchain open source
Belum lama ini hal itu mustahil, dan paling banter yang ada hanya Xilinx PetaLinux beserta tetek bengek proprietarinya
iCE40 LP1K yang kecil pun bisa memuat SERV, bahkan QERV, tanpa masalah
Menakjubkan melihat betapa kecilnya implementasi RISC-V yang sepenuhnya kompatibel bisa dibuat
Open hardware dan open software akhirnya bekerja bersama, dan dalam 10 tahun ke depan ini akan menjadi gelombang yang sangat besar
Arahnya mirip, tetapi jalurnya berbeda
Desain saya berbasis VexRiscv dan seluruh hardware ditulis dalam SpinalHDL
Karena SRAM pada board Karnix dibatasi 512KB, Linux masih belum bisa dijalankan, tetapi sudah ada Ethernet dan HDMI
Saya juga mengimplementasikan adapter video mirip CGA dengan antarmuka HDMI yang mendukung grafis 320x240x4 dan mode teks 80x30x16, serta smooth scrolling berbantuan hardware
Jika tertarik, README singkatnya ada di sini: https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...
Proyek KiCAD untuk board: https://github.com/Fabmicro-LLC/Karnix_ASB-254
Kerja yang keren
Senang melihat karya saya tentang diverse double-compiling (DDC) untuk menangani serangan trusting trust dikutip dengan cukup menonjol
Jika tertarik pada DDC, lihat di sini: https://dwheeler.com/trusting-trust
Bagus juga bahwa sistemnya dibangun ulang di atas dirinya sendiri dan memverifikasi apakah bitfile-nya identik
Fakta bahwa ini bisa dibangun ulang dalam 512MB, dan hanya memakan waktu 4,5 jam pada CPU sekitar 65MHz, cukup mengejutkan
Dari pengalaman saya memakai yosys atau vivado dan semacamnya, biasanya rasanya butuh beberapa GB
Disebutkan bahwa CPU 65MHz yang mampu menjalankan Linux mengingatkan pada Intel 486 dan Pentium generasi pertama pertengahan 1990-an, tetapi kombinasi 50~65MHz dan 512MB ini tampak lebih mirip workstation Unix awal 1990-an
Dari sisi RAM malah bisa dibilang lebih baik
Sebagai referensi, pada lowRISC/50MHz, linpack double-precision mencapai 4.5 Mflops
Pada 2022 saya mencoba hal serupa dengan LiteX, tetapi karena memakai FPGA Kintex-7, setidaknya saat itu Vivado tetap diperlukan untuk placement and routing yang sesungguhnya, jadi itu bukan self-hosting
Meski begitu, hasilnya tetap sebuah laptop open gateware yang bisa menjalankan Linux dan Xorg, berkat Linux-on-LiteX-VexRiscV: https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.h...
Shakti berbasis RISC-V dari IIT-Madras di India juga layak dilihat: Open Source Processor Development Ecosystem - https://shakti.org.in/
Ringkasan di Wikipedia juga bagus: https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)
Orang ini adalah orang yang sama yang dulu juga mengerjakan menjalankan OS X di qemu/kvm: https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/
Keren sekali
Sudah lama saya merasa kita sangat membutuhkan mesin RISC-V yang benar-benar self-hosting
Batasan terbesar saat ini sepertinya adalah mencari board FPGA dengan RAM onboard yang cukup
Board target di sini tampaknya punya 512MB, tetapi toolchain FPGA biasanya jauh lebih nyaman jika bisa memakai beberapa GB
Ide tentang perangkat keras dan perangkat lunak yang self-hosting itu bagus, tetapi saya bahkan tidak bisa membayangkan penderitaan membangun sesuatu seperti GCC di CPU 60MHz
Lagi pula, Rocket CPU ditulis dalam Scala
Saya baru-baru ini berhenti memakai Gentoo di RockPro64 karena waktu kompilasinya tidak tertahankan
Sistem itu pun beberapa orde magnitudo lebih cepat daripada yang ingin dipakai di sini
Banyak dari core bebas dan open source seperti ini memang belum dioptimalkan sama sekali, atau ditujukan untuk ASIC sehingga performanya sangat buruk di FPGA
Jika core yang dirancang dengan baik dipasang pada FPGA modern, selama bukan komponen Lattice kelas bawah berdaya rendah seperti ini, 250MHz atau lebih sangat mungkin dicapai dengan mikroarsitektur yang lebih kuat
Hanya saja itu tidak murah dan tidak mudah, jadi jarang terlihat di ranah hobi
Selain itu, FPGA yang lebih bagus sering kali tidak punya toolchain bebas dan open source, jadi juga kurang cocok dengan semangat perangkat lunak bebas
Meski begitu, bahkan di 250MHz, menjalankan Chipyard pada soft core akan menjadi latihan kesabaran
Namun saya setuju bahwa untuk mengompilasi semua yang Anda inginkan bisa saja memakan waktu seminggu
Tentu saja, ada juga metode cross-compiling
Itu juga bukan kejadian yang terlalu lama lalu
Komputer pertama yang saya gunakan berjalan kira-kira di 1MHz
Di mesin yang lambat, kompilasi memang akan makan waktu lebih lama, tetapi itu sendiri bukan masalah besar
Jika komputernya stabil dan skrip build-nya benar, Anda bisa membiarkannya berjalan selama berhari-hari atau berminggu-minggu
Dalam hidup saya, saya sudah sering menjalankan pekerjaan yang memakan waktu berhari-hari atau berminggu-minggu
Lihat “compiling”: https://xkcd.com/303/
Masalah yang sebenarnya adalah debugging
Debugging di sistem yang lambat bisa menyiksa karena siklus iterasinya menjadi panjang
Secara historis, ini diatasi dengan membagi tahap-tahapnya dan membuatnya bisa dimulai ulang dari beberapa titik, sehingga tidak perlu mengulang seluruh proses setiap kali
Pendekatan yang sama juga berlaku di sini
Selain itu, ada juga opsi untuk men-debug skrip di sistem yang lebih cepat tetapi kurang dapat diandalkan, lalu menjalankannya di sistem yang lambat setelah dipastikan berfungsi