Computador de auto-hospedagem RISC-V de 64 bits com suporte confiável a Linux livre/open source
(contrib.andrew.cmu.edu)- O objetivo é criar uma stack livre/open source auto-hospedada em que todo o funcionamento possa ser rastreado até HDL publicado e código-fonte de software, e na qual até a toolchain possa ser reconstruída e executada sobre o próprio sistema
- Como não é possível fabricar um ASIC diretamente, o hardware é colocado sobre FPGA, e a geração do bitstream e a programação também precisam ser feitas com ferramentas livres/open source
- Considera-se que a abordagem com FPGA dificulta que a foundry descubra o uso real e o posicionamento sensível de bits, limitando ataques na etapa de fabricação ao nível de DoS
- Como FPGAs têm uma estrutura de grade regular, uma inspeção visual destrutiva com técnicas como remoção química e imageamento por TEM é mais viável do que em um ASIC dedicado
- O problema de confiança que resta é tornar HDL, software, compilador e toolchain inteiramente construíveis a partir de código aberto, restringindo o escopo de verificação a código auditável
Condições para um computador confiável
- O objetivo é construir, do zero, um computador livre/open source, de modo que todo o funcionamento de hardware e software possa ser explicado por HDL público e código-fonte de software
- O compilador e a toolchain relacionada que constroem todo o sistema também precisam ser livres/open source e devem poder ser compilados e executados nesse próprio computador
- Em resultado, o que se busca é uma stack de hardware + software livre/open source auto-hospedada
- Como não se possui nem se controla uma foundry de silício, os componentes de hardware são implementados sobre FPGA
- A programação do FPGA e a geração do bitstream também precisam ser feitas com ferramentas livres/open source para que o modelo de confiança seja mantido
O compromisso de confiabilidade oferecido pelo FPGA
- O uso de FPGA é um compromisso prático escolhido em vez de fabricar diretamente um ASIC dedicado
- É difícil para a foundry do chip saber para que o FPGA será usado ou onde os chamados privilege bit ficarão posicionados dentro do chip
- Nessas condições, acredita-se que backdoors de hardware para escalonamento de privilégios possam ser mitigados, e que ataques inseridos na etapa de fabricação do FPGA fiquem limitados a DoS
- O computador pode até parar completamente, mas a chance de parecer funcionar normalmente enquanto trai seu proprietário é considerada menor
- Como o FPGA tem uma estrutura regular em grade com componentes idênticos repetidos, considera-se que a inspeção visual destrutiva é mais viável do que em um ASIC dedicado
- Exemplos incluem remoção química e imageamento por TEM
- Mesmo após reduzir a superfície de ataque da etapa de fabricação, continuam existindo riscos como código-fonte malicioso ou toolchains comprometidas
- Esse problema é tratado exigindo que todo HDL, software e toolchain sejam construíveis a partir de código-fonte público
Materiais de referência e experimentos de implementação
- FOSDEM 23: slides e apresentação recentes
- linux-on-litex-rocket: instruções de build mais recentes
- self-hosting demo: demonstração de auto-hospedagem
- CReSCT 2020 Paper, Slides, Presentation: materiais de apresentação relacionados ao IEEE S&P 2020
- lowRISC project: foi útil para entender os componentes, mas na época dependia de toolchain de HDL fechada e módulos de IP proprietários, como controlador de DRAM
- yoloRISC: demo SoC blinky baseado em Rocket-Chip RV64IMAC para a placa Lattice ECP5 5G Versa
1 comentários
Opiniões no Hacker News
Em teoria, poderia haver uma CPU escondida dentro do FPGA, e ela também poderia ter acesso de leitura/escrita a todo o programa do FPGA
Além disso, se a produção de FPGAs aumentar para o mesmo sistema ou para a próxima geração, a foundry obteria informações adicionais e poderia estimar muito bem onde ficam os bits de privilégio
De forma mais simples, também seria possível carregar código no FPGA e analisá-lo diretamente
Ao comprar um FPGA grande, ele vem com núcleos ARM, e todos esses núcleos ARM executam no EL3 um blob assinado e opaco que o usuário não pode substituir
Isso não é um soft core sobre o fabric, mas silício dedicado, e também pode acessar o ICAP dos dispositivos Xilinx, isto é, a porta interna de acesso à configuração, além de funcionalidades equivalentes de outros fabricantes
DRAMs modernas têm muitos recursos complexos, como link training, targeted refresh e correção de erros on-die, e mesmo sem conhecer a implementação exata há complexidade suficiente para esconder um backdoor
Seria possível incluir uma função que monitore padrões específicos de acesso à memória e, quando o padrão correto for detectado, conceda permissões arbitrárias de leitura/escrita
Isso permitiria escalar privilégios a partir de código não confiável, mas em sandbox, como JavaScript; e, como leituras arbitrárias de memória podem descobrir onde escrever, poderia funcionar independentemente da arquitetura da CPU ou do sistema operacional
Seria menos eficaz em DIMMs ou módulos de memória com vários chips, mas computadores RISC-V normalmente são pequenos computadores de placa única com apenas um chip de DRAM
Ele não aparece no código-fonte, mas se injeta sozinho no binário
Thompson demonstrou isso em condições controladas, mas, na prática, para um backdoor desses escapar da detecção, seria preciso um nível de astúcia quase próximo de uma AGI
Ele teria de continuar funcionando e se propagando mesmo com a evolução do hardware e do software, mantendo baixos os indícios como tamanho ou tempo de execução
Recriar a computação moderna sobre uma base completamente diferente, desse jeito, dificultaria e complicaria bastante o uso desse tipo de backdoor
https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_...
Claro que isso seria totalmente impraticável para vigilância indiscriminada em larga escala, mas a história pode mudar se um ator estatal souber que alguma organização está usando essa técnica para evitar monitoramento e que sua configuração de software é previsível
O posicionamento não é fixo, e não há um mapeamento consistente entre LUTs/FFs de hardware e as funções sintetizadas
É realmente impressionante poder fazer login em um shell Linux em um FPGA orangecrab rodando um softcore RISC-V compilado com um toolchain open source
Até pouco tempo atrás isso era impossível e, na melhor das hipóteses, o que havia era Xilinx PetaLinux e a tralha proprietária deles
Até em um pequeno iCE40 LP1K cabem sem problema o SERV, e até o QERV
É surpreendente ver o quanto uma implementação totalmente compatível de RISC-V pode ficar pequena
Hardware aberto e software aberto finalmente estão funcionando juntos, e isso vai se tornar uma tendência enorme dentro de 10 anos
Estou indo em uma direção parecida, mas por outro caminho
Meu projeto é baseado no VexRiscv e todo o hardware é escrito em SpinalHDL
Como a SRAM da placa Karnix é limitada a 512 KB, ainda não dá para rodar Linux, mas há Ethernet e HDMI
Também implementei, sobre a interface HDMI, um adaptador de vídeo parecido com CGA, com suporte a modos gráficos 320x240x4 e texto 80x30x16, além de rolagem suave assistida por hardware
Se houver interesse, há um README curto aqui: https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...
Projeto KiCAD da placa: https://github.com/Fabmicro-LLC/Karnix_ASB-254
Excelente trabalho
Fiquei contente ao ver meu trabalho sobre compilação dupla diversificada (DDC) contra ataques trusting trust citado com destaque
Se tiver interesse em DDC, veja aqui: https://dwheeler.com/trusting-trust
É bom reconstruir o sistema sobre ele mesmo e verificar se o bitfile é idêntico
É surpreendente que ele possa ser reconstruído em 512 MB e que tenha levado “apenas” 4,5 horas em uma CPU de cerca de 65 MHz
Pela minha experiência com yosys, vivado etc., a sensação é que normalmente eles exigem vários GB
Foi dito que uma CPU capaz de rodar Linux a 65 MHz lembra os Intel 486 de meados dos anos 1990 e os Pentium de primeira geração, mas a combinação de 50–65 MHz com 512 MB parece mais próxima de uma workstation Unix do início dos anos 1990
Em termos de RAM, pode-se até dizer que é melhor
Como referência, no lowRISC/50MHz, o linpack de dupla precisão faz 4,5 Mflops
Em 2022 fiz algo parecido com LiteX, mas usei um FPGA Kintex-7, então pelo menos naquela época ainda era necessário o Vivado para posicionamento e roteamento reais, portanto não era self-hosting
Ainda assim, saiu um notebook com gateware aberto rodando Linux e Xorg, graças ao Linux-on-LiteX-VexRiscV: https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.h...
Também vale conferir o Shakti, baseado em RISC-V, do IIT-Madras, na Índia: Open Source Processor Development Ecosystem - https://shakti.org.in/
A visão geral da Wikipedia também é boa: https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)
Essa é a mesma pessoa que, no passado, trabalhou em coisas relacionadas a rodar o OS X no qemu/kvm: https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/
Realmente muito legal
Há algum tempo venho pensando que precisamos muito de uma máquina RISC-V totalmente auto-hospedada
A maior limitação agora parece ser encontrar uma placa FPGA com RAM onboard suficiente
A placa-alvo aqui parece ter 512 MB, mas toolchains de FPGA normalmente ficam bem mais confortáveis quando podem usar alguns GB
A ideia de hardware e software auto-hospedados é boa, mas nem consigo imaginar o sofrimento de compilar algo como o GCC em uma CPU de 60 MHz
Além disso, a Rocket CPU é escrita em Scala
Recentemente parei de usar Gentoo no RockPro64 porque os tempos de compilação ficaram insuportáveis
Aquele sistema também é várias ordens de magnitude mais rápido do que o que se pretende usar aqui
Muitos desses núcleos livres e open source simplesmente não são muito otimizados, ou são voltados a ASICs e acabam tendo desempenho muito ruim em FPGA
Com um núcleo bem projetado em um FPGA moderno, desde que não seja uma peça Lattice de baixíssimo consumo como esta, é perfeitamente possível chegar a 250 MHz ou mais com uma microarquitetura mais forte
Só que isso não é barato nem fácil, então não aparece muito no meio hobbyista
Além disso, FPGAs melhores muitas vezes não têm toolchains livres e open source, o que também não combina muito com o espírito do software livre
Ainda assim, mesmo a 250 MHz, rodar o Chipyard em um softcore seria um exercício de paciência
Dito isso, concordo que compilar tudo o que você quiser pode levar uma semana
Claro, também existe a opção de compilação cruzada
E nem faz tanto tempo assim
Meus primeiros computadores rodavam por volta de 1 MHz
Em máquinas lentas, a compilação vai demorar mais, mas isso em si não é um grande problema
Se o computador for estável e os scripts de build estiverem corretos, basta deixá-lo rodando por dias ou semanas
Já rodei muitos trabalhos na vida que levavam dias ou semanas
Veja “compiling”: https://xkcd.com/303/
O verdadeiro problema é o debugging
Fazer debugging em um sistema lento pode ser penoso porque o ciclo de iteração fica longo
Historicamente, isso foi resolvido dividindo o processo em etapas e permitindo reiniciar a partir de vários pontos, para não precisar repetir tudo do zero a cada vez
A mesma abordagem funciona aqui
Além disso, há a opção de depurar os scripts em um sistema mais rápido, porém menos confiável, e então executá-los no sistema lento depois de confirmar que funcionam