Máy tính tự lưu trữ RISC-V 64-bit đáng tin cậy, hỗ trợ Linux tự do/mã nguồn mở

 (contrib.andrew.cmu.edu)
1 điểm bởi GN⁺ 2024-05-20 | 1 bình luận | Chia sẻ qua WhatsApp
  • Mục tiêu là tạo ra một stack tự lưu trữ tự do/mã nguồn mở trong đó toàn bộ hoạt động có thể được truy vết về HDL công khai và mã nguồn phần mềm, đồng thời toolchain cũng được xây dựng lại và chạy ngay trên hệ thống đó
  • Vì không thể tự chế tạo ASIC, phần cứng được đưa lên FPGA, và cả việc tạo bitstream lẫn lập trình cũng phải được xử lý bằng công cụ tự do/mã nguồn mở
  • Cách tiếp cận FPGA được cho là khiến foundry khó biết FPGA sẽ được dùng thực tế vào đâu và các bit nhạy cảm được bố trí ở vị trí nào, qua đó có thể giới hạn tấn công ở giai đoạn chế tạo xuống mức DoS
  • FPGA có cấu trúc lưới đều đặn nên kiểm tra trực quan mang tính phá hủy như bóc tách bằng hóa chất và chụp ảnh TEM được xem là thực tế hơn so với ASIC chuyên dụng
  • Vấn đề niềm tin còn lại nằm ở việc làm cho HDL, phần mềm, compiler và toolchain đều có thể được build từ mã nguồn mở, thu hẹp phạm vi xác minh về mã nguồn có thể kiểm toán

Điều kiện cho một máy tính đáng tin cậy

  • Mục tiêu là xây dựng một máy tính tự do/mã nguồn mở từ nền tảng thấp nhất, để toàn bộ hoạt động của phần cứng và phần mềm có thể được giải thích bằng HDL công khai và mã nguồn phần mềm
  • Compiler và các toolchain liên quan dùng để tạo ra toàn bộ hệ thống cũng phải là tự do/mã nguồn mở, đồng thời có thể được build và chạy trên chính máy tính đó
  • Kết quả cần có là một stack phần cứng + phần mềm tự do/mã nguồn mở tự lưu trữ
  • Vì không sở hữu hay kiểm soát silicon foundry, các thành phần phần cứng được triển khai trên FPGA
  • Việc lập trình FPGA và tạo bitstream cũng phải được xử lý bằng công cụ tự do/mã nguồn mở để duy trì mô hình tin cậy

Sự đánh đổi về độ tin cậy mà FPGA mang lại

  • Sử dụng FPGA là sự đánh đổi thực tế được chọn thay vì tự tạo ASIC chuyên dụng
    • Chip foundry khó biết FPGA sẽ được dùng vào đâu, và cái gọi là privilege bit sẽ được bố trí ở đâu trong chip
    • Trong điều kiện này, có thể giảm thiểu backdoor phần cứng leo thang đặc quyền, và các tấn công có thể cài ở giai đoạn chế tạo FPGA được xem là bị giới hạn ở DoS
    • Nhận định là máy tính có thể bị dừng hoàn toàn, nhưng khả năng nó giả vờ hoạt động bình thường trong khi phản bội chủ sở hữu sẽ thấp hơn
  • FPGA có cấu trúc lưới đều đặn với các thành phần giống nhau lặp lại, nên kiểm tra trực quan mang tính phá hủy được xem là khả thi hơn so với ASIC chuyên dụng
    • Ví dụ là bóc tách bằng hóa chất và chụp ảnh TEM
  • Ngay cả sau khi giảm bề mặt tấn công ở giai đoạn chế tạo, các rủi ro như mã nguồn độc hại hoặc toolchain độc hại vẫn còn
    • Vấn đề này được xử lý bằng cách yêu cầu mọi HDL, phần mềm và toolchain phải là mã nguồn công khai có thể build được

Tài liệu tham khảo và thử nghiệm triển khai

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-05-20
Các ý kiến trên Hacker News

  • Về lý thuyết, có thể có một CPU ẩn bên trong FPGA, và nó cũng có thể có quyền đọc/ghi đối với toàn bộ chương trình FPGA
    Ngoài ra, nếu sản lượng FPGA tăng lên cho cùng hệ thống hoặc thế hệ tiếp theo, foundry sẽ có thêm thông tin và có thể suy đoán khá tốt các bit quyền nằm ở đâu
    Đơn giản hơn nữa là cũng có thể nạp mã lên FPGA để phân tích trực tiếp

    • Ngày nay tất cả đều có cấu trúc như vậy. Chúng thậm chí không bị ẩn
      Nếu mua FPGA lớn, bên trong có lõi ARM, và tất cả các lõi ARM đó chạy ở EL3 những blob đã ký mờ đục mà người dùng không thể thay thế
      Đây không phải là soft core trên fabric mà là silicon chuyên dụng, và nó có thể truy cập ICAP trên thiết bị Xilinx, tức cổng truy cập cấu hình nội bộ, cũng như các chức năng tương đương của các nhà sản xuất khác
    • Có lẽ cài backdoor vào RAM sẽ dễ hơn
      DRAM hiện đại có nhiều chức năng phức tạp như link training, targeted refresh, sửa lỗi on-die, và dù không biết chính xác cách triển khai, độ phức tạp đó cũng đủ để che giấu backdoor
      Có thể thêm chức năng giám sát một mẫu truy cập bộ nhớ cụ thể, rồi khi phát hiện đúng mẫu thì cung cấp quyền đọc/ghi tùy ý
      Như vậy có thể dùng để leo thang đặc quyền từ mã không đáng tin cậy nhưng bị sandbox như JavaScript; vì có thể dùng đọc bộ nhớ tùy ý để tìm vị trí cần ghi, nó cũng có thể hoạt động độc lập với kiến trúc CPU hay hệ điều hành
      Cách này có lẽ kém hiệu quả hơn với DIMM hoặc các module bộ nhớ gồm nhiều chip, nhưng máy tính RISC-V thường là máy tính bo mạch đơn nhỏ chỉ có một chip DRAM
    • Cách này giống Thompson hack, trong đó một trình biên dịch độc hại có backdoor tự lan truyền
      Nó không xuất hiện trong mã nguồn nhưng tự tiêm vào binary
      Thompson đã trình diễn điều này trong điều kiện kiểm soát, nhưng trên thực tế, để một backdoor như vậy tránh bị phát hiện thì gần như cần mức tinh vi ngang AGI
      Nó phải tiếp tục hoạt động và lan truyền khi phần cứng lẫn phần mềm tiến hóa, đồng thời luôn giữ các dấu vết như kích thước hay thời gian chạy ở mức thấp
      Việc xây dựng lại điện toán hiện đại trên một nền tảng hoàn toàn khác như thế này sẽ cản trở và làm phức tạp đáng kể việc dùng kiểu backdoor đó
      https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_...
    • Tôi cũng tự hỏi liệu rình I/O rồi bằng cách nào đó tuồn dữ liệu ra ngoài có dễ hơn không
      Tất nhiên điều đó hoàn toàn không thực tế cho giám sát đại trà quy mô lớn, nhưng câu chuyện có thể khác nếu một tác nhân quốc gia biết rằng một tổ chức nào đó đang dùng kỹ thuật này để tránh bị theo dõi và cấu hình phần mềm của họ cũng có thể dự đoán được
    • Ngay cả nếu có CPU như vậy, việc tìm ra thanh ghi hay cổng nào trên FPGA triển khai thành phần nào của soft CPU cũng sẽ cực kỳ khó
      Vị trí không cố định, và cũng không có ánh xạ nhất quán giữa LUT/FF phần cứng với chức năng đã được tổng hợp

  • Thật đáng kinh ngạc khi có thể đăng nhập vào shell Linux trên một FPGA orangecrab chạy softcore RISC-V được build bằng toolchain mã nguồn mở
    Cách đây không lâu điều này còn bất khả thi, cùng lắm cũng chỉ là Xilinx PetaLinux và mớ độc quyền linh tinh của họ

    • Điều thú vị là ngay cả FPGA của orangecrab cũng không bắt buộc
      SERV, thậm chí cả QERV, đều nhét vừa không vấn đề gì trong iCE40 LP1K nhỏ
      Thật đáng ngạc nhiên khi một triển khai RISC-V tương thích đầy đủ có thể nhỏ đến mức nào
    • Có vẻ điều này sẽ sớm trở thành chất xúc tác để cộng đồng tụ lại
      Phần cứng mở và phần mềm mở cuối cùng cũng đang hoạt động cùng nhau, và trong vòng 10 năm nữa đây sẽ là một làn sóng rất lớn

  • Tôi đang đi theo hướng tương tự nhưng con đường thì khác
    Thiết kế của tôi dựa trên VexRiscv và toàn bộ phần cứng được viết bằng SpinalHDL
    SRAM của bo Karnix bị giới hạn ở 512KB nên vẫn chưa chạy được Linux, nhưng có Ethernet và HDMI
    Tôi cũng đã triển khai qua giao diện HDMI một bộ chuyển đổi video kiểu CGA, hỗ trợ chế độ đồ họa 320x240x4 và văn bản 80x30x16, với cuộn mượt có hỗ trợ phần cứng
    Nếu quan tâm, README ngắn ở đây: https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...
    Dự án KiCAD cho bo mạch: https://github.com/Fabmicro-LLC/Karnix_ASB-254

  • Công trình rất ấn tượng
    Tôi rất vui khi thấy công trình đa dạng hóa biên dịch kép (DDC) của mình nhằm chống lại tấn công trusting trust được trích dẫn nổi bật
    Nếu quan tâm đến DDC, xem tại đây: https://dwheeler.com/trusting-trust

  • Việc build lại hệ thống trên chính nó và xác minh bitfile có giống hệt không là rất tốt
    Thật đáng ngạc nhiên là nó có thể được build lại trong 512MB, và trên CPU khoảng 65MHz mà “chỉ” mất 4,5 giờ
    Theo kinh nghiệm dùng yosys hay vivado, tôi có cảm giác chúng thường đòi hỏi vài GB
    Người ta nói CPU 65MHz chạy được Linux gợi nhớ đến Intel 486 giữa thập niên 1990 và Pentium thế hệ đầu, nhưng tổ hợp 50–65MHz với 512MB trông giống workstation Unix đầu thập niên 1990 hơn
    Về RAM thì thậm chí có thể coi là tốt hơn
    Để tham khảo, linpack độ chính xác kép trên lowRISC/50MHz đạt 4,5 Mflops

  • Năm 2022 tôi đã thử một thứ tương tự bằng LiteX, nhưng vì dùng FPGA Kintex-7 nên ít nhất vào thời điểm đó vẫn cần Vivado để place-and-route thực tế, vì vậy chưa phải tự host
    Dù vậy cũng đã tạo ra một laptop open gateware chạy Linux và Xorg, nhờ Linux-on-LiteX-VexRiscV: https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.h...

  • Cũng đáng tham khảo Shakti dựa trên RISC-V của IIT-Madras, Ấn Độ: Open Source Processor Development Ecosystem - https://shakti.org.in/
    Phần tổng quan trên Wikipedia cũng khá hay: https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)

  • Đây chính là người trước đây từng làm về việc chạy OS X trên qemu/kvm: https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

  • Thật sự rất tuyệt
    Tôi đã nghĩ một thời gian rằng chúng ta rất cần một máy RISC-V hoàn toàn tự host
    Có vẻ hạn chế lớn nhất hiện nay là tìm được bo mạch FPGA có đủ RAM onboard
    Bo mạch được nhắm tới ở đây có vẻ là 512MB, nhưng toolchain FPGA thường thoải mái hơn nhiều khi có thể dùng vài GB

  • Ý tưởng về phần cứng và phần mềm tự host thì hay, nhưng không thể tưởng tượng nổi nỗi khổ khi build những thứ như GCC trên CPU 60MHz
    Hơn nữa Rocket CPU được viết bằng Scala
    Gần đây tôi đã ngừng dùng Gentoo trên RockPro64 vì thời gian biên dịch không thể chịu nổi
    Hệ thống đó còn nhanh hơn thứ định dùng ở đây vài bậc độ lớn

    • Có thể làm nhanh hơn nhiều
      Nhiều core tự do/mã nguồn mở kiểu này hoặc hầu như không được tối ưu, hoặc nhắm tới ASIC nên chạy trên FPGA có hiệu năng rất tệ
      Nếu đưa một core được thiết kế tốt lên FPGA hiện đại, không phải loại linh kiện Lattice tiết kiệm điện cấp thấp nhất như thế này, thì với vi kiến trúc mạnh hơn, 250MHz trở lên hoàn toàn khả thi
      Chỉ là nó không rẻ cũng không dễ, nên không thường thấy trong giới hobby
      Ngoài ra, FPGA tốt hơn thường không có toolchain tự do/mã nguồn mở, nên cũng không thật sự phù hợp với tinh thần phần mềm tự do
      Dù vậy, ngay cả ở 250MHz, chạy Chipyard trên softcore vẫn sẽ là một bài rèn luyện sự kiên nhẫn
    • Trước đây người ta từng làm việc thật sự trên hệ thống SPARC 50MHz, với ngoại vi cũng chậm hơn nhiều như Ethernet 10Mbps và ổ SCSI chậm, RAM cũng ít hơn và chậm hơn
      Tuy nhiên tôi đồng ý rằng nếu muốn biên dịch mọi thứ mình cần thì có thể mất cả tuần
      Tất nhiên vẫn có cách biên dịch chéo
    • Cũng có những người còn nhớ cảm giác build những thứ như GCC trên CPU 60MHz là như thế nào
      Chuyện đó cũng chưa xa xưa lắm
    • Đã từng có thời kỳ sở hữu một chiếc máy tính chạy nhanh tới 60MHz là mơ ước
      Những máy tính đầu tiên tôi dùng chạy khoảng 1MHz
      Trên máy chậm thì biên dịch sẽ mất lâu hơn, nhưng bản thân điều đó không phải vấn đề lớn
      Nếu máy tính ổn định và script build đúng, cứ để nó chạy vài ngày hoặc vài tuần là được
      Trong đời tôi đã chạy nhiều tác vụ mất vài ngày hoặc vài tuần
      Xem “compiling”: https://xkcd.com/303/
      Vấn đề thật sự là debug
      Debug trên hệ thống chậm có thể rất khổ vì vòng lặp thử-sửa kéo dài
      Trong lịch sử, người ta giải quyết bằng cách chia thành các bước và cho phép khởi động lại từ nhiều điểm khác nhau để không phải lặp lại toàn bộ quy trình mỗi lần
      Cách đó cũng hiệu quả ở đây
      Ngoài ra, cũng có lựa chọn debug script trên một hệ thống nhanh hơn nhưng kém tin cậy hơn, rồi khi đã xác nhận chạy được thì mới chạy trên hệ thống chậm