भरोसेमंद, free/open-source Linux-सपोर्टेड 64-bit RISC-V self-hosting कंप्यूटर

 (contrib.andrew.cmu.edu)
1 पॉइंट द्वारा GN⁺ 2024-05-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लक्ष्य एक ऐसा self-hosting free/open-source stack बनाना है, जिसमें पूरे व्यवहार को खुले HDL और software source तक trace किया जा सके, और उसी system पर toolchain तक को दोबारा build और run किया जा सके
  • सीधे ASIC नहीं बनाया जा सकता, इसलिए hardware को FPGA पर चलाया जाता है, और bitstream generation व programming भी free/open-source tools से ही होनी चाहिए
  • FPGA approach से foundry के लिए असली उपयोग और sensitive bit placement जानना मुश्किल हो जाता है, जिससे manufacturing-stage attacks को DoS स्तर तक सीमित किया जा सकता है
  • नियमित grid structure वाले FPGA में chemical removal और TEM imaging जैसी destructive visual inspection dedicated ASIC की तुलना में ज्यादा व्यावहारिक मानी जाती है
  • बचा हुआ trust issue यह है कि HDL, software, compiler और toolchain सभी को open source से build करने योग्य बनाया जाए, ताकि verification scope को auditable source तक सीमित किया जा सके

भरोसेमंद कंप्यूटर के लिए शर्तें

  • लक्ष्य bottom-up तरीके से free/open-source कंप्यूटर बनाना है, ताकि hardware और software के पूरे व्यवहार को खुले HDL और software source से समझाया जा सके
  • पूरे system को बनाने वाले compiler और संबंधित toolchain भी free/open-source होने चाहिए, और उसी कंप्यूटर पर build होकर run हो सकने चाहिए
  • परिणामस्वरूप जरूरत एक self-hosting free/open-source hardware+software stack की है
  • silicon foundry का स्वामित्व या control नहीं है, इसलिए hardware components को FPGA पर implement किया जाता है
  • trust model बनाए रखने के लिए FPGA programming और bitstream generation भी free/open-source tools से ही होना चाहिए

FPGA से मिलने वाला trust compromise

  • FPGA का इस्तेमाल dedicated ASIC खुद बनाने के बजाय चुना गया एक practical compromise है
    • chip foundry के लिए यह जानना मुश्किल होता है कि FPGA कहां इस्तेमाल होगा, और तथाकथित privilege bit chip के अंदर कहां रखा जाएगा
    • इन स्थितियों में privilege-escalation hardware backdoor को mitigate किया जा सकता है, और FPGA manufacturing stage में लगाए जा सकने वाले attacks DoS तक सीमित माने जाते हैं
    • यानी कंप्यूटर पूरी तरह बंद हो सकता है, लेकिन सामान्य रूप से काम करने का नाटक करते हुए owner को धोखा देने की संभावना कम हो जाती है
  • FPGA में समान components का repeat होने वाला regular grid structure होता है, इसलिए dedicated ASIC की तुलना में destructive visual inspection ज्यादा संभव मानी जाती है
    • उदाहरण chemical removal और TEM imaging हैं
  • manufacturing-stage attack surface घटाने के बाद भी malicious source या toolchain जैसे risks बाकी रहते हैं
    • इस समस्या को सभी HDL, software और toolchain को buildable public source के रूप में मांगकर handle किया जाता है

संदर्भ सामग्री और implementation experiments

  • FOSDEM 23: हालिया slides और talk
  • linux-on-litex-rocket: नवीनतम build instructions
  • self-hosting demo: self-hosting demo
  • CReSCT 2020 Paper, Slides, Presentation: IEEE S&P 2020 से संबंधित presentation material
  • lowRISC project: components समझने में उपयोगी था, लेकिन उस समय closed HDL toolchain और DRAM controller जैसे proprietary IP modules पर निर्भर था
  • yoloRISC: Lattice ECP5 5G Versa board के लिए RV64IMAC Rocket-Chip आधारित blinky demo SoC

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-20
Hacker News की राय

  • सैद्धांतिक रूप से देखा जाए तो FPGA के अंदर छिपा हुआ CPU हो सकता है, और पूरे FPGA प्रोग्राम पर read/write access भी हो सकता है
    साथ ही, अगर उसी सिस्टम या अगली पीढ़ी के लिए FPGA का उत्पादन बढ़ता है, तो foundry को अतिरिक्त जानकारी मिल जाएगी, और वह काफी अच्छी तरह अनुमान लगा सकती है कि permission bit कहाँ है
    और भी सरल तरीके से, FPGA पर कोड डालकर सीधे analysis भी किया जा सकता है

    • आजकल सब कुछ इसी तरह की संरचना का है। यह छिपा हुआ भी नहीं है
      बड़ा FPGA खरीदें तो उसमें ARM core होता है, और वे सभी ARM core EL3 में ऐसे opaque signed blob चलाते हैं जिन्हें user replace नहीं कर सकता
      यह fabric पर soft core नहीं, बल्कि dedicated silicon है, और Xilinx devices के ICAP, यानी internal configuration access port, तथा दूसरे manufacturers की समान functionality तक भी access कर सकता है
    • RAM में backdoor लगाना शायद ज्यादा आसान होगा
      आधुनिक DRAM में link training, targeted refresh, on-die error correction जैसे जटिल features बहुत हैं, और exact implementation न पता हो तब भी backdoor छिपाने के लिए पर्याप्त complexity है
      किसी खास memory access pattern को monitor करके, सही pattern detect होने पर arbitrary read/write permission देने वाली functionality जोड़ी जा सकती है
      इससे JavaScript जैसे untrusted लेकिन sandboxed code में privilege escalation के लिए इस्तेमाल किया जा सकता है, और arbitrary memory read से लिखने की जगह खोजी जा सकती है, इसलिए यह CPU architecture या operating system से स्वतंत्र होकर भी काम कर सकता है
      DIMM या कई chips वाले memory modules में यह कम असरदार होगा, लेकिन RISC-V computer आम तौर पर छोटे single-board computer होते हैं जिनमें केवल एक DRAM chip होती है
    • यह तरीका उस Thompson hack जैसा है जिसमें malicious compiler खुद फैलने वाला backdoor रखता है
      source code में यह दिखाई नहीं देता, लेकिन binary में खुद inject हो जाता है
      Thompson ने नियंत्रित परिस्थितियों में इसे demonstrate किया था, लेकिन वास्तविकता में ऐसे backdoor को detection से बचना हो तो लगभग AGI-स्तर की चालाकी चाहिए
      hardware और software evolve होते रहें तब भी इसे लगातार काम करना और फैलना होगा, और size या execution time जैसे traces भी लगातार कम रखने होंगे
      इस तरह modern computing को बिल्कुल अलग आधार पर फिर से बनाना ऐसे backdoor के इस्तेमाल को काफी बाधित और जटिल बना देगा
      https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_...
    • मुझे यह भी लगता है कि I/O पर नजर रखना और किसी तरह data बाहर निकालना शायद ज्यादा आसान न हो?
      बेशक बड़े पैमाने की indiscriminate surveillance के लिए यह पूरी तरह अव्यावहारिक होगा, लेकिन अगर किसी state actor को पता हो कि कोई संगठन surveillance से बचने के लिए यह तकनीक इस्तेमाल कर रहा है और software configuration भी predictable है, तो बात अलग हो सकती है
    • भले ही ऐसा CPU मौजूद हो, FPGA पर कौन-सा register या gate soft CPU के किस component को implement करता है, यह पता लगाना बेहद मुश्किल होगा
      placement fixed नहीं होती, और hardware LUT/FF तथा synthesized function के बीच कोई consistent mapping भी नहीं होती

  • open source toolchain से build किए गए RISC-V softcore पर चल रहे orangecrab FPGA में Linux shell से login कर पाना सचमुच हैरान करने वाला है
    कुछ समय पहले तक यह असंभव था, और बहुत हुआ तो Xilinx PetaLinux और उनका proprietary कचरा ही विकल्प था

    • दिलचस्प बात यह है कि orangecrab का FPGA भी जरूरी नहीं है
      छोटे iCE40 LP1K में भी SERV, बल्कि QERV तक बिना समस्या के फिट हो जाता है
      पूरी तरह compatible RISC-V implementation कितनी छोटी हो सकती है, यह चौंकाने वाला है
    • लगता है जल्द ही community इसके इर्द-गिर्द एकजुट होगी
      open hardware और open software आखिरकार साथ काम कर रहे हैं, और 10 साल के भीतर यह बहुत बड़ी लहर बनेगा

  • दिशा मिलती-जुलती है, लेकिन रास्ता अलग है
    मेरा design VexRiscv based है और सारा hardware SpinalHDL में लिखा गया है
    Karnix board की SRAM 512KB तक सीमित होने के कारण अभी Linux नहीं चला सकता, लेकिन Ethernet और HDMI हैं
    320x240x4 graphics और 80x30x16 text mode support करने वाला, hardware-assisted smooth scrolling वाला CGA जैसा video adapter भी HDMI interface के रूप में implement किया है
    रुचि हो तो छोटा README यहाँ है: https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...
    board के लिए KiCAD project: https://github.com/Fabmicro-LLC/Karnix_ASB-254

  • शानदार काम है
    trusting trust attack के खिलाफ मेरे diverse double-compiling (DDC) work को प्रमुखता से cite किया गया देखकर अच्छा लगा
    DDC में रुचि हो तो यहाँ देखें: https://dwheeler.com/trusting-trust

  • system को उसी पर फिर से build करना और bitfile identical है या नहीं verify करना अच्छा है
    यह हैरान करता है कि 512MB में rebuild हो सकता है, और लगभग 65MHz CPU पर “सिर्फ” 4.5 घंटे लगे
    yosys या vivado आदि इस्तेमाल करने के अनुभव से लगता था कि आम तौर पर कई GB चाहिए होते हैं
    कहा गया कि 65MHz Linux-capable CPU 1990 के दशक के मध्य के Intel 486 और पहली generation Pentium की याद दिलाता है, लेकिन 50~65MHz और 512MB का combination 1990 के शुरुआती Unix workstation के करीब लगता है
    RAM के मामले में तो इसे बेहतर भी कहा जा सकता है
    संदर्भ के लिए, lowRISC/50MHz पर double-precision linpack 4.5 Mflops है

  • 2022 में LiteX से कुछ ऐसा ही किया था, लेकिन Kintex-7 FPGA इस्तेमाल किया था, इसलिए कम से कम उस समय actual place-and-route के लिए Vivado चाहिए था और self-hosting नहीं थी
    फिर भी Linux और Xorg चलाने वाला open gateware laptop मिला, Linux-on-LiteX-VexRiscV की बदौलत: https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.h...

  • भारत के IIT-Madras का RISC-V आधारित Shakti भी देखने लायक है: Open Source Processor Development Ecosystem - https://shakti.org.in/
    Wikipedia का overview भी अच्छा है: https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)

  • यह वही व्यक्ति है जिसने पहले qemu/kvm पर OS X चलाने से जुड़ा काम भी किया था: https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

  • वाकई शानदार
    मैं कुछ समय से सोच रहा था कि पूरी तरह self-hosted RISC-V machine की सख्त जरूरत है
    अभी सबसे बड़ी सीमा शायद पर्याप्त onboard RAM वाला FPGA board ढूँढना है
    यहाँ target board 512MB का लगता है, जबकि FPGA toolchain आम तौर पर कुछ GB इस्तेमाल कर सके तो कहीं ज्यादा सहज रहता है

  • self-hosting hardware और software का idea अच्छा है, लेकिन 60MHz CPU पर GCC जैसी चीज़ build करने की पीड़ा की कल्पना भी नहीं कर सकता
    ऊपर से Rocket CPU Scala में लिखा गया है
    मैंने हाल ही में RockPro64 पर Gentoo इस्तेमाल करना छोड़ दिया, क्योंकि compile time सहन नहीं हो रहा था
    वह system भी यहाँ इस्तेमाल होने वाले system से कई orders of magnitude तेज है

    • इसे कहीं ज्यादा तेज बनाया जा सकता है
      इन free/open source cores में से कई या तो बिल्कुल optimize नहीं किए गए हैं, या ASIC को target करते हैं, इसलिए FPGA पर performance बहुत खराब आती है
      अगर well-designed core को modern FPGA पर चलाया जाए, और ऐसे सबसे निचले दर्जे के low-power Lattice parts न हों, तो stronger microarchitecture के साथ 250MHz या उससे ज्यादा भी पूरी तरह संभव है
      बस यह न सस्ता है न आसान, इसलिए hobby space में ज्यादा दिखता नहीं है
      साथ ही बेहतर FPGA के लिए अक्सर free/open source toolchain नहीं होते, इसलिए यह free software भावना से भी बहुत मेल नहीं खाता
      फिर भी 250MHz पर भी softcore में Chipyard चलाना धैर्य की परीक्षा ही होगा
    • पहले 50MHz SPARC systems पर असली काम किया जाता था, और peripherals भी 10Mbps Ethernet और धीमी SCSI drives जैसे कहीं ज्यादा धीमे थे, RAM भी कम और धीमी थी
      हालांकि मैं मानता हूँ कि जो कुछ चाहिए वह सब compile करने में एक हफ्ता लग सकता है
      बेशक cross-compilation का रास्ता भी है
    • कुछ लोगों को याद है कि 60MHz CPU पर GCC जैसी चीज़ build करना कैसा लगता था
      यह बहुत पुरानी बात भी नहीं है
    • एक समय था जब 60MHz जितनी तेज चलने वाली computer होना भी सपना था
      मैंने जो पहले computers इस्तेमाल किए, वे लगभग 1MHz पर चलते थे
      धीमी machine पर compilation में ज्यादा समय लगेगा, लेकिन अपने आप में यह बड़ी समस्या नहीं है
      अगर computer stable है और build scripts सही हैं, तो उसे कई दिन या कई हफ्ते बस चलने दें
      मैंने जिंदगी में कई ऐसे jobs चलाए हैं जिन्हें दिनों या हफ्तों लगे
      “compiling” देखें: https://xkcd.com/303/
      असली समस्या debugging है
      धीमे system पर debugging करने से iteration cycle लंबी हो जाती है और यह परेशान कर सकता है
      इतिहास में इसे चरणों में बाँटकर और कई points से restart करने लायक बनाकर हल किया गया, ताकि हर बार पूरा process दोहराना न पड़े
      यहाँ भी वही तरीका काम करेगा
      साथ ही, एक विकल्प यह भी है कि scripts को किसी तेज लेकिन कम भरोसेमंद system पर debug किया जाए, और जब काम करना confirm हो जाए तो धीमे system पर चलाया जाए