คอมพิวเตอร์ self-hosting แบบ 64 บิต RISC-V ที่น่าเชื่อถือ รองรับ Linux แบบเสรี/โอเพนซอร์ส

 (contrib.andrew.cmu.edu)
1 คะแนน โดย GN⁺ 2024-05-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป้าหมายคือการสร้าง สแตกเสรี/โอเพนซอร์สแบบ self-hosting ที่สามารถติดตามการทำงานทั้งหมดกลับไปยัง HDL และซอร์สซอฟต์แวร์ที่เปิดเผยได้ และสามารถบิลด์·รัน toolchain ใหม่บนระบบนั้นเองได้
  • เนื่องจากไม่สามารถผลิต ASIC เองได้ ฮาร์ดแวร์จึงถูกวางบน FPGA และการสร้าง bitstream กับการโปรแกรมก็ต้องจัดการด้วยเครื่องมือเสรี/โอเพนซอร์สด้วย
  • มองว่าแนวทาง FPGA ทำให้ foundry รู้ได้ยากว่า FPGA จะถูกใช้งานจริงอย่างไร และตำแหน่ง bit ที่อ่อนไหวถูกจัดวางตรงไหน จึงสามารถจำกัดการโจมตีในขั้นตอนการผลิตให้อยู่ในระดับ DoS ได้
  • FPGA ที่มีโครงสร้างตารางสม่ำเสมอทำให้ การตรวจสอบด้วยภาพแบบทำลายชิ้นส่วน เช่น การกัดลอกทางเคมีและการถ่ายภาพ TEM มีความเป็นไปได้จริงมากกว่า ASIC เฉพาะทาง
  • ปัญหาความเชื่อมั่นที่เหลืออยู่คือการทำให้ HDL·ซอฟต์แวร์·คอมไพเลอร์·toolchain ทั้งหมดสามารถบิลด์ได้จากซอร์สเปิด เพื่อลดขอบเขตการตรวจสอบให้เหลือเป็น ซอร์สที่ตรวจสอบได้

เงื่อนไขสำหรับคอมพิวเตอร์ที่เชื่อถือได้

  • เป้าหมายคือการสร้างคอมพิวเตอร์เสรี/โอเพนซอร์สตั้งแต่ฐานราก เพื่อให้สามารถอธิบายการทำงานทั้งหมดของฮาร์ดแวร์และซอฟต์แวร์ได้ด้วย HDL และซอร์สซอฟต์แวร์ที่เปิดเผย
  • คอมไพเลอร์และ toolchain ที่เกี่ยวข้อง สำหรับสร้างระบบทั้งหมดก็ต้องเป็นเสรี/โอเพนซอร์ส และต้องสามารถบิลด์และรันบนคอมพิวเตอร์เครื่องนั้นได้
  • ผลลัพธ์ที่ต้องการคือสแตกฮาร์ดแวร์+ซอฟต์แวร์เสรี/โอเพนซอร์สแบบ self-hosting
  • เนื่องจากไม่ได้เป็นเจ้าของหรือควบคุม silicon foundry ส่วนประกอบฮาร์ดแวร์จึงถูกใช้งานบน FPGA
  • การโปรแกรม FPGA และการสร้าง bitstream ก็ต้องจัดการด้วยเครื่องมือเสรี/โอเพนซอร์สเช่นกัน เพื่อรักษาโมเดลความเชื่อมั่นไว้

การประนีประนอมด้านความเชื่อมั่นที่ FPGA มอบให้

  • การใช้ FPGA เป็นการประนีประนอมที่ปฏิบัติได้จริง แทนการสร้าง ASIC เฉพาะทางเอง
    • chip foundry จะรู้ได้ยากว่า FPGA จะถูกนำไปใช้ที่ไหน และสิ่งที่เรียกว่า privilege bit จะถูกวางไว้ตรงไหนภายในชิป
    • ภายใต้เงื่อนไขนี้ สามารถบรรเทาแบ็กดอร์ฮาร์ดแวร์ที่ยกระดับสิทธิ์ได้ และมองว่าการโจมตีที่ฝังได้ในขั้นตอนการผลิต FPGA จะถูกจำกัดอยู่ที่ DoS
    • แม้คอมพิวเตอร์อาจหยุดทำงานโดยสมบูรณ์ได้ แต่โอกาสที่จะทำเหมือนทำงานปกติขณะทรยศต่อเจ้าของจะลดลง
  • FPGA มีโครงสร้างตารางสม่ำเสมอที่ประกอบด้วยองค์ประกอบเดิมซ้ำ ๆ จึงมองว่า การตรวจสอบด้วยภาพแบบทำลายชิ้นส่วน เป็นไปได้มากกว่า ASIC เฉพาะทาง
    • ตัวอย่างคือการกัดลอกทางเคมีและการถ่ายภาพ TEM
  • แม้จะลดพื้นผิวการโจมตีในขั้นตอนการผลิตแล้ว ความเสี่ยงอย่างซอร์สหรือ toolchain ที่เป็นอันตรายก็ยังคงอยู่
    • ปัญหานี้จัดการด้วยการกำหนดให้ HDL·ซอฟต์แวร์·toolchain ทั้งหมดต้องเป็นซอร์สเปิดที่บิลด์ได้

เอกสารอ้างอิงและการทดลองใช้งานจริง

  • FOSDEM 23: สไลด์และการบรรยายล่าสุด
  • linux-on-litex-rocket: คำแนะนำการบิลด์ล่าสุด
  • self-hosting demo: เดโม self-hosting
  • CReSCT 2020 Paper, Slides, Presentation: เอกสารการบรรยายที่เกี่ยวข้องกับ IEEE S&P 2020
  • lowRISC project: มีประโยชน์ต่อการทำความเข้าใจส่วนประกอบ แต่ในเวลานั้นยังพึ่งพา toolchain HDL แบบปิดและโมดูล IP กรรมสิทธิ์ เช่น DRAM controller
  • yoloRISC: เดโม SoC แบบ blinky ที่ใช้ RV64IMAC Rocket-Chip สำหรับบอร์ด Lattice ECP5 5G Versa

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-05-20
ความคิดเห็นจาก Hacker News

  • ในทางทฤษฎี อาจมี CPU ที่ซ่อนอยู่ภายใน FPGA และมันอาจมีสิทธิ์อ่าน/เขียนเข้าถึงโปรแกรมทั้งหมดของ FPGA ได้
    อีกอย่าง หากปริมาณการผลิต FPGA สำหรับระบบเดียวกันหรือรุ่นถัดไปเพิ่มขึ้น โรงงานผลิตชิปก็จะได้ข้อมูลเพิ่มเติม และน่าจะคาดเดาได้ค่อนข้างดีว่าบิตสิทธิ์อยู่ตรงไหน
    หรือแบบง่ายกว่านั้น ก็อาจโหลดโค้ดลง FPGA แล้ววิเคราะห์โดยตรงได้

    • สมัยนี้ทั้งหมดก็เป็นโครงสร้างแบบนั้นอยู่แล้ว ไม่ได้ซ่อนด้วยซ้ำ
      ถ้าซื้อ FPGA ขนาดใหญ่ จะมี คอร์ ARM อยู่ข้างใน และคอร์ ARM เหล่านั้นทั้งหมดจะรัน blob ที่เซ็นชื่อแล้วแบบทึบซึ่งผู้ใช้เปลี่ยนไม่ได้ที่ EL3
      นี่ไม่ใช่ซอฟต์คอร์บนแฟบริก แต่เป็นซิลิคอนเฉพาะ และสามารถเข้าถึง ICAP ของอุปกรณ์ Xilinx ซึ่งก็คือพอร์ตเข้าถึงการกำหนดค่าภายใน รวมถึงฟังก์ชันเทียบเท่าของผู้ผลิตรายอื่น ๆ ได้ด้วย
    • การฝัง แบ็กดอร์ไว้ใน RAM น่าจะง่ายกว่า
      DRAM สมัยใหม่มีฟีเจอร์ซับซ้อนมากมาย เช่น link training, targeted refresh และ on-die error correction และแม้จะไม่รู้การนำไปใช้งานจริงอย่างละเอียด ความซับซ้อนก็เพียงพอที่จะซ่อนแบ็กดอร์ได้
      อาจใส่ฟังก์ชันที่คอยเฝ้าดูรูปแบบการเข้าถึงหน่วยความจำเฉพาะ และเมื่อพบรูปแบบที่ถูกต้องก็ให้สิทธิ์อ่าน/เขียนตามอำเภอใจได้
      แบบนี้สามารถใช้ยกระดับสิทธิ์จากโค้ดที่ไม่น่าเชื่อถือแต่ถูก sandbox อย่าง JavaScript ได้ และเพราะสามารถใช้การอ่านหน่วยความจำตามอำเภอใจเพื่อหาตำแหน่งที่จะเขียน จึงทำงานได้โดยไม่ขึ้นกับสถาปัตยกรรม CPU หรือระบบปฏิบัติการ
      อาจได้ผลน้อยกว่ากับ DIMM หรือโมดูลหน่วยความจำที่มีหลายชิป แต่คอมพิวเตอร์ RISC-V มักเป็นคอมพิวเตอร์บอร์ดเดี่ยวขนาดเล็กที่มีชิป DRAM เพียงตัวเดียว
    • วิธีแบบนี้คล้ายกับ Thompson hack ที่คอมไพเลอร์ประสงค์ร้ายมีแบ็กดอร์ที่แพร่ตัวเองได้
      มันไม่ปรากฏในซอร์สโค้ด แต่จะฉีดตัวเองเข้าไปในไบนารี
      Thompson สาธิตสิ่งนี้ภายใต้เงื่อนไขที่ควบคุมได้ แต่ในโลกจริง หากแบ็กดอร์แบบนั้นจะหลบการตรวจจับได้ ก็แทบต้องมีความแนบเนียนระดับใกล้เคียง AGI
      มันต้องทำงานและแพร่ต่อไปได้แม้ฮาร์ดแวร์และซอฟต์แวร์จะวิวัฒน์ไป และยังต้องรักษาร่องรอยอย่างขนาดหรือเวลาในการรันให้ต่ำอยู่เสมอ
      งานในการสร้างคอมพิวติ้งยุคใหม่ขึ้นใหม่บนฐานที่ต่างออกไปโดยสิ้นเชิงแบบนี้ จะขัดขวางและทำให้การใช้แบ็กดอร์ลักษณะนี้ซับซ้อนขึ้นมาก
      https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_...
    • ผมก็สงสัยว่า การแอบดู I/O แล้วหาทางดึงข้อมูลออกไปน่าจะง่ายกว่าหรือเปล่า
      แน่นอนว่าสำหรับการสอดส่องแบบเหวี่ยงแหในระดับใหญ่ มันไม่สมจริงเลย แต่ถ้าผู้กระทำระดับรัฐรู้ว่าองค์กรบางแห่งใช้เทคนิคนี้เพื่อหลบเลี่ยงการเฝ้าระวัง และคอนฟิกซอฟต์แวร์ก็พอคาดเดาได้ เรื่องก็อาจต่างออกไป
    • ต่อให้มี CPU แบบนั้นจริง การจะหาว่ารีจิสเตอร์หรือเกตใดบน FPGA ใช้ประกอบส่วนใดของซอฟต์ CPU ก็จะยากสุด ๆ
      การวางตำแหน่งไม่ได้คงที่ และไม่มีการแมปที่สม่ำเสมอระหว่าง LUT/FF ของฮาร์ดแวร์กับฟังก์ชันที่สังเคราะห์ขึ้น

  • น่าทึ่งจริง ๆ ที่สามารถล็อกอินเข้า Linux shell บน orangecrab FPGA ที่รัน RISC-V softcore ซึ่งบิลด์ด้วย ทูลเชนโอเพนซอร์ส ได้
    ไม่นานก่อนหน้านี้ยังเป็นไปไม่ได้ และอย่างมากก็คงได้แค่ Xilinx PetaLinux กับของจิปาถะปิดของพวกเขา

    • ที่น่าสนใจคือ แม้แต่ FPGA ของ orangecrab ก็ไม่ได้จำเป็นด้วยซ้ำ
      แม้แต่ iCE40 LP1K ขนาดเล็กก็ใส่ SERV หรือแม้กระทั่ง QERV ได้สบาย
      น่าทึ่งว่าการใช้งาน RISC-V ที่เข้ากันได้สมบูรณ์สามารถเล็กลงได้ขนาดไหน
    • น่าจะกลายเป็นจุดที่ชุมชนมารวมตัวกันในไม่ช้า
      ฮาร์ดแวร์เปิดและซอฟต์แวร์เปิด ในที่สุดก็ทำงานร่วมกันได้แล้ว และภายใน 10 ปีจะกลายเป็นกระแสใหญ่มาก

  • กำลังไปในทิศทางคล้ายกัน แต่คนละเส้นทาง
    งานออกแบบของผมอิง VexRiscv และฮาร์ดแวร์ทั้งหมดเขียนด้วย SpinalHDL
    SRAM ของบอร์ด Karnix จำกัดอยู่ที่ 512KB เลยยังรัน Linux ไม่ได้ แต่มี Ethernet และ HDMI
    ผมยังทำอะแดปเตอร์วิดีโอคล้าย CGA ที่รองรับโหมดกราฟิก 320x240x4 และโหมดข้อความ 80x30x16 พร้อม smooth scrolling แบบช่วยด้วยฮาร์ดแวร์ ผ่านอินเทอร์เฟซ HDMI ด้วย
    ถ้าสนใจ README สั้น ๆ อยู่ที่นี่: https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...
    โปรเจกต์ KiCAD สำหรับบอร์ด: https://github.com/Fabmicro-LLC/Karnix_ASB-254

  • เป็นงานที่ยอดเยี่ยม
    ดีใจที่เห็นงาน diverse double-compiling (DDC) ของผมเพื่อตอบโต้การโจมตี trusting trust ถูกอ้างถึงอย่างเด่นชัด
    ถ้าสนใจ DDC ดูได้ที่นี่: https://dwheeler.com/trusting-trust

  • การบิลด์ระบบใหม่บนตัวมันเองและ ตรวจสอบว่า bitfile เหมือนกันหรือไม่ ถือว่าดี
    น่าทึ่งที่มันสามารถบิลด์ใหม่ได้ใน 512MB และใช้เวลา “แค่” 4.5 ชั่วโมงบน CPU ราว 65MHz
    จากประสบการณ์ที่เคยใช้ yosys หรือ vivado ผมรู้สึกว่าปกติมันต้องการหน่วยความจำหลาย GB
    มีคนบอกว่า CPU 65MHz ที่รัน Linux ได้ชวนให้นึกถึง Intel 486 และ Pentium รุ่นแรกช่วงกลางทศวรรษ 1990 แต่ชุด 50~65MHz กับ 512MB ดูใกล้เคียงเวิร์กสเตชัน Unix ช่วงต้นทศวรรษ 1990 มากกว่า
    ด้าน RAM อาจถือว่าดีกว่าด้วยซ้ำ
    อ้างอิงคือ linpack แบบ double precision บน lowRISC/50MHz ได้ 4.5 Mflops

  • ในปี 2022 ผมเคยทำอะไรคล้าย ๆ กันด้วย LiteX แต่ใช้ Kintex-7 FPGA ดังนั้นอย่างน้อยในตอนนั้นยังต้องใช้ Vivado สำหรับการ place-and-route จริง จึงไม่ใช่การโฮสต์ตัวเอง
    ถึงอย่างนั้นก็ได้โน้ตบุ๊กเกตแวร์เปิดที่รัน Linux และ Xorg ได้ ต้องขอบคุณ Linux-on-LiteX-VexRiscV: https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.h...

  • Shakti ที่ใช้ RISC-V ของ IIT-Madras ในอินเดียก็น่าดูเป็นข้อมูลอ้างอิง: Open Source Processor Development Ecosystem - https://shakti.org.in/
    ภาพรวมใน Wikipedia ก็ดี: https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)

  • คนนี้คือคนเดียวกับที่เคยทำงานเกี่ยวกับการ รัน OS X บน qemu/kvm มาก่อน: https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

  • เจ๋งมากจริง ๆ
    ผมคิดมาสักพักแล้วว่าเราต้องการ เครื่อง RISC-V ที่โฮสต์ตัวเองได้อย่างสมบูรณ์จริง ๆ
    ข้อจำกัดใหญ่ที่สุดตอนนี้น่าจะเป็นการหา FPGA board ที่มี RAM บนบอร์ดมากพอ
    บอร์ดเป้าหมายที่นี่ดูเหมือนจะมี 512MB แต่ FPGA toolchain มักจะใช้งานได้สบายกว่ามากเมื่อมีหน่วยความจำให้ใช้ได้สักหลาย GB

  • ไอเดียเรื่องฮาร์ดแวร์และซอฟต์แวร์ที่โฮสต์ตัวเองได้นั้นดี แต่จินตนาการไม่ออกเลยว่าการ บิลด์อะไรอย่าง GCC บน CPU 60MHz จะทรมานแค่ไหน
    แถม Rocket CPU ยังเขียนด้วย Scala อีก
    ช่วงหลังผมเลิกใช้ Gentoo บน RockPro64 เพราะทนเวลาคอมไพล์ไม่ไหว
    ระบบนั้นยังเร็วกว่าสิ่งที่จะใช้ที่นี่อยู่หลายลำดับขั้น

    • สามารถทำให้เร็วขึ้นได้มาก
      คอร์เสรี/โอเพนซอร์สจำนวนมากเหล่านี้ไม่ค่อยถูกปรับแต่งเลย หรือไม่ก็ออกแบบมาเพื่อ ASIC ทำให้ประสิทธิภาพบน FPGA ออกมาแย่มาก
      ถ้านำคอร์ที่ออกแบบดีไปลงบน FPGA สมัยใหม่ ไม่ใช่ชิ้นส่วน Lattice กินไฟต่ำระดับล่างสุดแบบนี้ ก็สามารถทำไมโครสถาปัตยกรรมที่แรงกว่าและได้ 250MHz ขึ้นไป อย่างสบาย
      เพียงแต่มันไม่ถูกและไม่ง่าย จึงไม่ค่อยเห็นในวงการงานอดิเรก
      อีกอย่าง FPGA ที่ดีกว่ามักไม่มี toolchain แบบเสรี/โอเพนซอร์ส จึงไม่ค่อยเข้ากับจิตวิญญาณซอฟต์แวร์เสรีนัก
      ถึงอย่างนั้น ต่อให้ที่ 250MHz การรัน Chipyard บน softcore ก็คงเป็นการฝึกความอดทนอยู่ดี
    • เมื่อก่อนเราเคยทำงานจริงบนระบบ SPARC 50MHz และอุปกรณ์รอบข้างก็ช้ากว่านี้มาก เช่น Ethernet 10Mbps กับไดรฟ์ SCSI ที่ช้า แถม RAM ก็น้อยกว่าและช้ากว่า
      แต่เห็นด้วยว่า ถ้าจะคอมไพล์ทุกอย่างที่ต้องการ อาจใช้เวลาถึงหนึ่งสัปดาห์ได้
      แน่นอนว่ายังมีวิธี cross-compile ด้วย
    • ยังมีคนที่จำได้ว่าการบิลด์อะไรอย่าง GCC บน CPU 60MHz รู้สึกอย่างไร
      ก็ไม่ได้เก่านานขนาดนั้น
    • ครั้งหนึ่ง การมีคอมพิวเตอร์ที่ทำงานเร็วถึง 60MHz เคยเป็นความฝัน
      คอมพิวเตอร์เครื่องแรก ๆ ที่ผมใช้ทำงานราว 1MHz
      บนเครื่องที่ช้า การคอมไพล์จะใช้เวลานานขึ้น แต่ตัวมันเองไม่ใช่ปัญหาใหญ่
      ถ้าคอมพิวเตอร์เสถียรและสคริปต์บิลด์ถูกต้อง ก็แค่ปล่อยให้รันไปหลายวันหรือหลายสัปดาห์
      ในชีวิตผมเคยรันงานที่ใช้เวลาหลายวันหรือหลายสัปดาห์มาเยอะแล้ว
      ดู “compiling”: https://xkcd.com/303/
      ปัญหาจริง ๆ คือ การดีบัก
      การดีบักบนระบบที่ช้าทำให้รอบการวนซ้ำยาวขึ้นและอาจทรมานได้
      ในอดีตแก้ด้วยการแบ่งเป็นขั้น ๆ และทำให้เริ่มใหม่ได้จากหลายจุด เพื่อไม่ต้องทำซ้ำทั้งกระบวนการทุกครั้ง
      ที่นี่ก็ใช้วิธีเดียวกันได้
      อีกทางเลือกหนึ่งคือดีบักสคริปต์บนระบบที่เร็วกว่าแต่เชื่อถือได้น้อยกว่า แล้วเมื่อยืนยันว่าใช้งานได้ จึงค่อยไปรันบนระบบที่ช้า