신뢰할 수 있는 자유/오픈소스 리눅스 지원 64비트 RISC-V 셀프 호스팅 컴퓨터

 (contrib.andrew.cmu.edu)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 목표는 전체 동작을 공개된 HDL과 소프트웨어 소스로 추적할 수 있고, 그 시스템 위에서 도구체인까지 다시 빌드·실행되는 셀프 호스팅 자유/오픈소스 스택을 만드는 것임
  • 직접 ASIC을 제작할 수 없으므로 하드웨어는 FPGA 위에 올리고, 비트스트림 생성과 프로그래밍도 자유/오픈소스 도구로 처리해야 함
  • FPGA 접근은 파운드리가 실제 사용처와 민감한 비트 배치를 알기 어렵게 만들어, 제작 단계 공격을 DoS 수준으로 제한할 수 있다고 봄
  • 규칙적인 격자 구조를 가진 FPGA는 화학적 제거와 TEM 이미징 같은 파괴적 시각 검사가 전용 ASIC보다 현실적인 편임
  • 남은 신뢰 문제는 HDL·소프트웨어·컴파일러·도구체인을 모두 공개 소스로 빌드 가능하게 만들어, 검증 범위를 감사 가능한 소스로 좁히는 데 있음

신뢰 가능한 컴퓨터를 위한 조건

  • 목표는 바닥부터 자유/오픈소스 컴퓨터를 구축해, 하드웨어와 소프트웨어 전체 동작을 공개된 HDL 및 소프트웨어 소스로 설명 가능하게 만드는 것임
  • 전체 시스템을 만드는 컴파일러와 관련 도구체인도 자유/오픈소스여야 하며, 해당 컴퓨터 위에서 빌드되고 실행될 수 있어야 함
  • 결과적으로 필요한 것은 셀프 호스팅 자유/오픈소스 하드웨어+소프트웨어 스택임
  • 실리콘 파운드리를 소유하거나 통제하지 못하므로, 하드웨어 구성요소는 FPGA 위에 구현함
  • FPGA 프로그래밍과 비트스트림 생성 역시 자유/오픈소스 도구로 처리해야 신뢰 모델이 유지됨

FPGA가 주는 신뢰성 절충

  • FPGA 사용은 전용 ASIC을 직접 만드는 대신 선택한 현실적인 절충임
    • 칩 파운드리는 FPGA가 어디에 쓰일지, 이른바 privilege bit가 칩 안에서 어디에 배치될지 알기 어려움
    • 이 조건에서는 권한 상승 하드웨어 백도어를 완화할 수 있고, FPGA 제작 단계에서 심을 수 있는 공격은 DoS로 제한된다고 봄
    • 컴퓨터가 완전히 멈출 수는 있어도, 정상 동작하는 척하면서 소유자를 배신할 가능성은 낮아진다는 판단임
  • FPGA는 동일한 구성요소가 반복되는 규칙적 격자 구조라서, 전용 ASIC보다 파괴적 시각 검사가 더 가능하다고 봄
    • 예시는 화학적 제거와 TEM 이미징임
  • 제작 단계의 공격 표면을 줄인 뒤에도 악성 소스나 도구체인 같은 위험은 남아 있음
    • 이 문제는 모든 HDL·소프트웨어·도구체인을 빌드 가능한 공개 소스로 요구하는 방식으로 다룸

참고 자료와 구현 실험

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이론적으로는 FPGA 안에 숨겨진 CPU가 있고, FPGA 프로그램 전체에 읽기/쓰기 접근을 할 수도 있다고 봄
    또 같은 시스템이나 다음 세대용으로 FPGA 생산량이 늘어나면 파운드리가 추가 정보를 얻게 되고, 권한 비트가 어디 있는지 꽤 잘 추정할 수 있음
    더 단순하게는 FPGA에 코드를 올려 직접 분석할 수도 있음

    • 요즘은 전부 그런 구조임. 숨겨져 있지도 않음
      큰 FPGA를 사면 ARM 코어가 들어 있고, 그 ARM 코어들은 모두 사용자가 교체할 수 없는 불투명한 서명된 blob을 EL3에서 실행함
      이건 패브릭 위의 소프트 코어가 아니라 전용 실리콘이고, Xilinx 장치의 ICAP, 즉 내부 구성 접근 포트와 다른 제조사들의 동등한 기능에도 접근할 수 있음
    • RAM에 백도어를 심는 편이 더 쉬울 것 같음
      현대 DRAM은 링크 트레이닝, 표적 리프레시, 온다이 오류 정정 같은 복잡한 기능이 많고, 정확한 구현은 몰라도 백도어를 숨기기에는 충분한 복잡성이 있음
      특정 메모리 접근 패턴을 감시하다가 올바른 패턴이 감지되면 임의 읽기/쓰기 권한을 제공하는 기능을 넣을 수 있을 것임
      이렇게 하면 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와 합성된 기능 사이에 일관된 매핑도 없음

  • 오픈 소스 툴체인으로 빌드한 RISC-V 소프트코어가 돌아가는 orangecrab FPGA에 Linux 셸로 로그인할 수 있다는 게 정말 놀라움
    얼마 전만 해도 불가능했고, 잘해봐야 Xilinx PetaLinux와 그들의 독점 잡동사니 정도였음

    • 재미있는 건 orangecrab의 FPGA조차 필수는 아니라는 점임
      작은 iCE40 LP1K에도 SERV, 심지어 QERV까지 문제없이 들어감
      완전 호환 RISC-V 구현이 얼마나 작아질 수 있는지 놀라움
    • 곧 커뮤니티가 결집하는 계기가 될 것 같음
      오픈 하드웨어와 오픈 소프트웨어가 마침내 함께 동작하고 있고, 10년 안에 아주 큰 흐름이 될 것임

  • 비슷한 방향으로 가고 있지만 경로는 다름
    내 설계는 VexRiscv 기반이고 모든 하드웨어는 SpinalHDL로 작성되어 있음
    Karnix 보드의 SRAM이 512KB로 제한되어 아직 Linux는 못 돌리지만, Ethernet과 HDMI가 있음
    그래픽 320x240x4와 텍스트 80x30x16 모드를 지원하고 하드웨어 보조 부드러운 스크롤이 되는 CGA 비슷한 비디오 어댑터도 HDMI 인터페이스로 구현했음
    관심 있으면 짧은 README는 여기 있음: https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...
    보드용 KiCAD 프로젝트: https://github.com/Fabmicro-LLC/Karnix_ASB-254

  • 멋진 작업임
    trusting trust 공격에 대응하는 내 다양한 이중 컴파일(DDC) 작업이 눈에 띄게 인용되어 있어서 반가웠음
    DDC에 관심 있으면 여기 참고: https://dwheeler.com/trusting-trust

  • 시스템을 자기 자신 위에서 다시 빌드하고 bitfile이 동일한지 검증하는 건 좋음
    512MB에서 다시 빌드될 수 있다는 점, 그리고 약 65MHz CPU에서 “겨우” 4.5시간 걸렸다는 점이 놀라움
    yosys나 vivado 등을 써본 경험으로는 보통 수 GB를 요구하는 느낌이었음
    65MHz Linux 가능 CPU는 1990년대 중반 Intel 486과 1세대 Pentium을 떠올리게 한다고 했지만, 50~65MHz와 512MB 조합은 1990년대 초반 Unix 워크스테이션에 가까워 보임
    RAM 쪽은 오히려 더 낫다고도 볼 수 있음
    참고로 lowRISC/50MHz에서 배정밀도 linpack은 4.5 Mflops임

  • 2022년에 비슷한 걸 LiteX로 해봤지만, Kintex-7 FPGA를 써서 적어도 당시에는 실제 배치·배선에 Vivado가 필요했기 때문에 자체 호스팅은 아니었음
    그래도 Linux와 Xorg가 돌아가는 오픈 게이트웨어 노트북이 나왔음, 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의 개요도 좋음: https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)

  • 이 사람이 예전에 qemu/kvm에서 OS X 실행 관련 작업도 했던 그 사람임: https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

  • 정말 멋짐
    완전히 자체 호스팅되는 RISC-V 머신이 절실히 필요하다고 한동안 생각해왔음
    지금 가장 큰 제한은 충분한 온보드 RAM을 가진 FPGA 보드를 찾는 일 같음
    여기 대상 보드는 512MB인 것 같은데, FPGA 툴체인은 보통 몇 GB를 쓸 수 있을 때 훨씬 편해함

  • 자체 호스팅 하드웨어와 소프트웨어라는 아이디어는 좋지만, 60MHz CPU에서 GCC 같은 걸 빌드하는 고통은 상상도 안 됨
    게다가 Rocket CPU는 Scala로 작성되어 있음
    최근 RockPro64에서 Gentoo 사용을 그만뒀는데, 컴파일 시간이 견딜 수 없었기 때문임
    그 시스템도 여기서 쓰려는 것보다 몇 자릿수는 빠름

    • 훨씬 더 빠르게 만들 수는 있음
      이런 자유·오픈 소스 코어들 중 상당수는 아예 최적화가 덜 되어 있거나 ASIC을 대상으로 해서 FPGA에서는 성능이 매우 나쁘게 나옴
      잘 설계한 코어를 현대적인 FPGA에 올리면, 이런 최하급 저전력 Lattice 부품이 아니라면 더 강한 마이크로아키텍처로 250MHz 이상도 충분히 가능함
      다만 싸지도 쉽지도 않아서 취미 영역에서 잘 안 보이는 것임
      또 더 좋은 FPGA는 자유·오픈 소스 툴체인이 없는 경우가 많아 자유 소프트웨어 정신에도 잘 맞지 않음
      그래도 250MHz에서도 소프트코어에서 Chipyard를 돌리는 건 인내심 훈련이 될 것임
    • 예전에는 50MHz SPARC 시스템으로 실제 일을 했고, 주변장치도 10Mbps Ethernet과 느린 SCSI 드라이브처럼 훨씬 느렸으며 RAM도 더 적고 느렸음
      다만 원하는 걸 전부 컴파일하려면 일주일 걸릴 수도 있다는 데는 동의함
      물론 교차 컴파일이라는 방법도 있음
    • 60MHz CPU에서 GCC 같은 걸 빌드하는 게 어떤 느낌인지 기억하는 사람들도 있음
      그리 오래전 일도 아님
    • 한때는 60MHz만큼 빠르게 도는 컴퓨터를 갖는 게 꿈이던 시절도 있었음
      처음 쓴 컴퓨터들은 대략 1MHz로 동작했음
      느린 기계에서는 컴파일이 더 오래 걸리겠지만, 그 자체는 큰 문제가 아님
      컴퓨터가 안정적이고 빌드 스크립트가 맞다면 며칠이나 몇 주 동안 그냥 돌려두면 됨
      살면서 며칠이나 몇 주 걸리는 작업을 많이 돌려봤음
      “compiling” 참고: https://xkcd.com/303/
      진짜 문제는 디버깅임
      느린 시스템에서 디버깅하면 반복 주기가 길어져 괴로울 수 있음
      역사적으로는 단계를 나누고 여러 지점에서 다시 시작할 수 있게 만들어 매번 전체 과정을 반복하지 않도록 해결했음
      여기서도 같은 방식이 통함
      추가로, 더 빠르지만 덜 신뢰할 수 있는 시스템에서 스크립트를 디버깅한 뒤, 동작이 확인되면 느린 시스템에서 실행하는 선택지도 있음
답변달기