A arquitetura dos sistemas de firmware baseados em ARMv8

Desde o seu lançamento em 2011, a arquitetura do processador ARMv8 tornou-se bastante difundida no mercado de dispositivos móveis. De acordo com as previsões do CEO da ARM Limited, os processadores desta geração irão adquirir uma quota de mercado mundial de até 25% até 2020. É bastante natural que o suporte de software tenha sido estabelecido e tenha se desenvolvido ainda mais herdando as funcionalidades e generalidades princípios da infraestrutura historicamente formada.

Uma situação fundamentalmente diferente é observada no segmento de servidores do mercado. Os servidores baseados em X86 têm dominado essa área há muito tempo, enquanto o ARMv8 está apenas encontrando seu caminho (e apenas em segmentos de negócios específicos). A novidade deste mercado para ARM e o fato de que a maioria dos padrões e especificações aceitos (principalmente ACPI e UEFI) não foram adaptados para sistemas ARM até recentemente, deixaram sua marca no desenvolvimento da infraestrutura de software.

Este artigo concentra-se em uma visão geral do sistema de servidor baseado em ARM e recursos do processador e não faz nenhuma pretensão de ser uma descrição exaustiva. Os autores também gostariam de chamar a atenção do leitor para o fato de que os dados fornecidos podem rapidamente se tornar obsoletos - em breve, novos processadores virão com novas soluções técnicas que podem exigir uma abordagem diferente para a implementação da infraestrutura de software.

Em primeiro lugar, devemos apontar que as implementações atuais de firmware para sistemas de servidor ARMv8 consistem em vários componentes relativamente independentes. Isso oferece uma série de vantagens, como a possibilidade de usar os mesmos componentes no firmware do servidor e dos sistemas incorporados, bem como a independência relativa das alterações introduzidas.

Então, quais módulos e componentes são usados ​​nesses sistemas e quais são suas funções? O gráfico geral para o carregamento e interação dos módulos é mostrado na Fig. 1. O processo começa com a inicialização dos subsistemas, como RAM e interfaces entre processadores. Nas implementações atuais, isso é executado por um módulo separado no modo EL3S imediatamente após ligar a alimentação da CPU principal. Assim, este componente do sistema possui o máximo de privilégios possíveis. Normalmente não interage diretamente com o sistema operacional.

Fig 1. O carregamento e interação dos módulos. (Fonte:Auriga)

Posteriormente, o controle é transferido para o próximo componente, geralmente o módulo ARM Trusted Firmware (ATF), que é executado no mesmo modo. O controle do ATF pode ser transferido diretamente do carregador de nível 0 descrito no parágrafo anterior ou indiretamente por meio de um módulo UEFI especial que implementa o PEI (Inicialização PreEFI). O ATF consiste em vários módulos que recebem o controle em momentos diferentes.

O módulo de inicialização BL1 executa a inicialização das partes da plataforma atribuídas ao modo de processador seguro. Como os sistemas baseados em ARMv8 usam separação de hardware para recursos confiáveis ​​e não confiáveis, incluindo RAM, o módulo BL1 prepara um ambiente onde o código confiável pode ser executado. Em particular, este tipo de inicialização inclui a configuração de controladores de memória / cache (zonas confiáveis ​​e não confiáveis ​​são marcadas através da programação dos registros nesses dispositivos) e marcação de dispositivos on-chip (controladores de memória independentes de energia). Essa marcação também introduz a filtragem de transações DMA com base nos tipos de dispositivos (confiáveis ​​/ não confiáveis). Diante de tudo isso, a gravação / leitura na memória só é possível de / para áreas cujas configurações de segurança correspondam às do dispositivo. As implementações de um ambiente confiável podem ser bastante complexas; por exemplo, eles podem incluir um sistema operacional separado. No entanto, a descrição de tais implementações está além do escopo deste artigo.

O módulo BL1 configura a tabela de tradução de endereços MMU, bem como a tabela de manipulador de exceções, onde o elemento mais importante é o manipulador de exceções para a instrução Secure Monitor Call (SMC). Nesse ponto, o manipulador é mínimo e pode, na verdade, apenas transferir o controle para imagens carregadas na RAM. Durante a execução, o módulo BL1 carrega o próximo estágio (BL2) na RAM e transfere o controle para ela. O módulo BL2 funciona no modo EL1S com privilégios reduzidos. Portanto, a transferência de controle para este módulo é realizada através da instrução “ERET”.

O objetivo do módulo BL2 é carregar os módulos de firmware restantes (partes BL3) e transferir o controle para eles. O nível de privilégio reduzido é usado para evitar possíveis danos ao código e aos dados EL3S já na memória. O código dessas partes é executado chamando o código EL3S localizado no estágio BL1 usando a instrução SMC.

O terceiro estágio de carregamento e inicialização do ATF pode consistir em três estágios, mas o segundo estágio geralmente é omitido. Assim, na verdade, apenas dois permanecem. O módulo BL3-1 é parte do código confiável que pode ser acessado por software de uso geral (SO, etc.) em tempo de execução. A parte principal deste módulo é o manipulador de exceções chamado pela instrução “SMC”. Existem funções no próprio módulo para implementar chamadas SMC padrão:o código que implementa a interface PSCI padrão (projetada para controlar toda a plataforma, como ativação / desativação de núcleos de processador, gerenciamento de energia em toda a plataforma e reinicialização) e também lida com o fornecedor -chamadas específicas (fornecendo informações sobre a plataforma, gerenciando dispositivos embarcados, etc.).

Conforme mencionado acima, a presença do módulo BL3-2 é opcional; seu código (no caso de um módulo) é executado no modo EL1S. Normalmente, ele serve como um serviço / monitor especializado para os eventos que ocorrem durante a operação da plataforma (interrupções de certos temporizadores, dispositivos, etc.)

Na verdade, BL3-3 não é um módulo ATF, mas uma imagem de firmware executado no modo não seguro. Geralmente assume o controle no modo EL2 e representa uma imagem de um bootloader semelhante ao U-Boot amplamente conhecido ou de um ambiente UEFI, que é padrão para sistemas de servidor.

O gráfico geral da inicialização do módulo ATF é mostrado na Fig. 2.

Fig. 2. Inicialização do módulo ATF. (Fonte:Auriga)