Redução da Superfície de Ataque de Firmware (FASR)
Em outubro de 2019, a Microsoft trabalhou em estreita colaboração com nossos parceiros OEM e de silício para lançar computadores de núcleo seguro. Esses dispositivos apresentam hardware, firmware e software profundamente integrados para ajudar a garantir maior segurança para os dispositivos, identidade e dados. Um dos principais pilares de segurança dos computadores de núcleo seguro é ajudar a oferecer proteção de firmware para os dispositivos. Um recurso fundamental baseado em hardware necessário para satisfazer esse pilar é a D-RTM (Raiz dinâmica de confiança para medição). No entanto, não há muitos dispositivos que oferecem D-RTM hoje devido à dependência do chipset subjacente para compatibilidade com esse recurso, o que impede nosso compromisso de ajudar a elevar e manter um alto nível de segurança para todos os dispositivos Windows.
Mais pode ser feito para aprimorar a postura de segurança de todos os dispositivos Windows, incluindo aqueles sem D-RTM. A Microsoft está trabalhando com parceiros para superar os problemas de compatibilidade que impediam que as proteções de memória fossem aplicadas no firmware UEFI, desenvolvendo um conjunto de aprimoramentos de segurança SMM de software de código aberto para fornecer flexibilidade adicional para os OEMs usarem.
Para refletir esse compromisso com a segurança do firmware, identificamos uma nova abordagem para garantir que os dispositivos possam atender aos requisitos de proteção de firmware dos computadores de núcleo seguro.
Visão geral do FASR
Para computadores de núcleo seguro que não têm recursos D-RTM baseados em hardware, devemos definir um pequeno conjunto de componentes de firmware que apresentam uma superfície de ataque reduzida e podem ser comprovados no sistema operacional. Essa abordagem é chamada de FASR (Redução da superfície de ataque de firmware). Para que o firmware baseado em FASR fosse dimensionado em computadores de diferentes fornecedores, uma nova abordagem para o processo de inicialização do firmware precisava ser definida.
O FASR suporta dois caminhos de inicialização:
Caminho de inicialização certificado:
Somente o código confiável, assinado e integrado pela Microsoft tem permissão para ser executado.
A violação do caminho de inicialização é detectável pelo sistema operacional.
A figura abaixo mostra o fluxo de inicialização do FASR S-RTM no caminho de inicialização certificado. Esse caminho de inicialização ajuda a impedir que o código de firmware da plataforma inesperado seja executado. No entanto, ele usa alguns dados específicos da plataforma fornecidos pelo caminho de inicialização personalizado. O diagrama a seguir mostra o fluxo de inicialização da FASR no caminho de inicialização certificado.
Caminho de inicialização personalizado: todo o código de firmware da plataforma pode ser executado. As informações críticas de inicialização específicas de um determinado OEM/plataforma são convertidas em dados no caminho de inicialização personalizado e usadas pelo caminho de inicialização certificado para configurar o sistema corretamente nesse caminho de inicialização. O diagrama a seguir mostra o fluxo de inicialização do FASR no caminho de inicialização personalizado.
Um dispositivo FASR habilitado para conformidade com o computador de núcleo seguro usa como padrão o caminho de inicialização certificado, a menos que tenha ocorrido um evento que faça com que a inicialização alterne para o caminho de inicialização personalizado no início do processo de inicialização do firmware. Exemplos desses eventos incluem uma atualização de firmware, o usuário solicitou uma interface do usuário de firmware ou o usuário optou por desabilitar o computador de núcleo seguro, o que significa que ele sempre inicializará no caminho de inicialização personalizado, até que ele seja reativado.
A inicialização personalizada pode ser usada para inicializar qualquer sistema operacional ou software de terceiros, conforme compatível com o firmware da plataforma em um dispositivo compatível com FASR, mas o Windows não reconhecerá a inicialização no caminho de inicialização personalizado como compatível com o computador de núcleo seguro.
Para entender melhor as tecnologias de segurança por trás do FASR, gostaríamos de compartilhar uma visão geral rápida do processo de inicialização do Windows.
Processo de inicialização do Windows
Raiz da confiança
A execução inicial do firmware em um computador moderno segue um processo de inicialização em que um conjunto inicial de código carrega outro código e o nível de funcionalidade se expande, à medida que a inicialização avança. Cada conjunto de código verifica o próximo conjunto de código, formando uma cadeia de confiança. Quando o firmware UEFI ganha controle, ele segue o padrão de inicialização segura de verificação de assinaturas de software para continuar a cadeia de confiança até o sistema operacional. Em seguida, o carregador de inicialização do Windows continua a cadeia de confiança com a Inicialização Confiável, que verifica todos os outros componentes do sistema operacional no processo de inicialização, antes de ser carregado.
Em geral, os invasores procuram obter controle o mais cedo possível no processo de inicialização, antes que os recursos de segurança e bloqueios que ajudam a proteger o sistema sejam ativados. Quando o sistema é retirado da redefinição, o conjunto inicial de código executado deve ser ancorado na confiança. A tecnologia de verificação de hardware que cumpre a função de executar essa verificação de código inicial é chamada de raiz de confiança. Embora os detalhes exatos variem de acordo com o fornecedor de hardware, todas as raízes de confiança normalmente estão enraizadas em hardware imutável ou ROMs no SOC.
Inicialização Medida
A inicialização segura ancorada em uma raiz de confiança ajuda a garantir que a assinatura digital de todo o firmware seja verificada. No entanto, também é desejável ter um registro de exatamente qual firmware foi executado. O Programa de compatibilidade de hardware do Windows requer que todos os computadores com Windows 10 e Windows 11 incluam um chip chamado TPM (Módulo de plataforma confiável). O TPM contém locais de memória chamados PCRs (Platform Configuration Registers, Registros de configuração de plataforma). Cada PCR contém o hash para um tipo de código e/ou dados carregados durante a inicialização, como código de firmware no dispositivo de armazenamento não volátil (por exemplo, flash SPI), ROMs de opção de dispositivos PCI ou o carregador de inicialização do sistema operacional. O tamanho de um valor que pode ser armazenado em um PCR é determinado pelo tamanho do resumo do algoritmo de hash suportado. Por exemplo, um PCR SHA-1 pode armazenar 20 bytes, enquanto um PCR SHA-2 pode armazenar 32 bytes. Vários PCRs associados ao mesmo algoritmo de hash são chamados de banco. A Especificação de perfil TPM do cliente do computador TCG define a inclusão de pelo menos um banco de PCR com 24 registros.
Com um TPM presente, cada componente de firmware também pode atualizar ou estender o PCR apropriado, conforme novos códigos e dados são carregados no processo de inicialização. O processo de extensão atualiza o valor de PCR para ser a saída do algoritmo de hash usando o valor de PCR atual concatenado com o novo código ou argumento de dados como entrada. O resultado é que os PCRs podem ser inspecionados após o processo de inicialização para determinar o que foi executado. Isso permite que o software no sistema operacional entenda se o processo de inicialização foi diferente das inicializações anteriores. Em um ambiente sensível à segurança, o sistema operacional pode ser informado sobre o conjunto exato de medidas de código esperadas em determinados PCRs para detectar a execução de código de firmware inesperado. Como os primeiros 16 PCRs em um banco só podem ser redefinidos reiniciando todo o TPM, eles são confiáveis e o local preferencial para armazenar medidas importantes no TPM.
Raiz de confiança para medição
Agora que examinamos a função de uma raiz de confiança e como a inicialização medida é usada, examinaremos duas abordagens comuns para estabelecer uma raiz de confiança para relatar uma cadeia de medidas ao TPM: estática e dinâmica.
Uma raiz estática de confiança para medição (S-RTM) estabelece confiança na reinicialização do sistema e exige que a confiança seja mantida durante todo o processo de inicialização. Se a confiança for comprometida em qualquer ponto do processo de inicialização, ela será irrecuperável até a reinicialização do sistema. O diagrama a seguir ilustra como o S-RTM é usado no caminho de inicialização certificado.
Por outro lado, o D-RTM (Raiz dinâmica de confiança para medição) confia apenas em uma pequena parte do código do firmware de inicialização inicial do chipset e em um agente de hardware é usado para restabelecer a confiança dinamicamente durante a inicialização. O sistema pode inicializar inicialmente em código de firmware não confiável, mas, logo após o lançamento, reverte para um estado confiável assumindo o controle de todas as CPUs e forçando-as a seguir um caminho bem conhecido e medido. O diagrama a seguir fornece uma visão geral de um fluxo D-RTM tradicional.
Há uma troca entre S-RTM e D-RTM. O S-RTM não requer recursos especiais de hardware, mas requer software para explicar melhor o código executado durante toda a inicialização. O D-RTM requer recursos especiais de hardware, mas permite que o software seja iniciado em um estado confiável dinamicamente durante a vida útil do sistema.
Os computadores Windows com núcleo protegido usaram um D-RTM no lançamento seguro para permitir flexibilidade para o amplo conjunto de fabricantes de sistemas implementarem recursos e experiências exclusivos no firmware, além de ajudar a garantir que o sistema possa atingir um estado confiável e medido que seja aceitável para hospedar um ambiente de sistema operacional seguro. Um evento de inicialização D-RTM é usado para restabelecer a confiança de um ambiente desconhecido, antes de carregar um kernel seguro. O diagrama a seguir mostra o evento de inicialização D-RTM para restabelecer um ambiente de sistema conhecido.
No passado, o S-RTM podia ser implementado em mais dispositivos devido à sua falta de dependência de recursos especiais de hardware para verificar o estado de segurança do sistema, mas o sistema operacional não tinha um método confiável para confirmar que podia confiar nas medições relatadas em um determinado dispositivo Windows usando o S-RTM.
Aprimoramentos de segurança de firmware
Minimize os componentes de firmware no caminho de inicialização do sistema operacional
Uma maneira de confiar nas medições S-RTM é reduzir os componentes de firmware que podem ser executados a um conjunto mínimo. Se todos os dispositivos que usam o S-RTM usassem o mesmo conjunto de componentes de firmware, o sistema operacional só precisaria confiar em um único conjunto de valores de PCR esperados para esses componentes conhecidos e confiáveis. Com essa abordagem baseada em SRTM, um dispositivo pode ser considerado como tendo atendido ao requisito de proteção de firmware de computadores de núcleo seguro, quando o conjunto de firmware de inicialização é verificado como contendo apenas software assinado pela Microsoft que pode ser atestado pelo Windows. Para entender melhor como esses componentes de firmware diferem daqueles em uma inicialização normal do computador, vamos examinar o processo de inicialização antes e depois.
Devido à flexibilidade e ao rico conjunto de recursos oferecidos pelo firmware de computador moderno, o código executado antes do sistema operacional resulta em uma superfície de ataque aumentada. O diagrama a seguir mostra um exemplo de um fluxo de inicialização S-RTM tradicional.
As principais responsabilidades do firmware durante a inicialização podem ser bastante simplificadas para:
Específico da plataforma: funcionalidade que se aplica apenas ao design de hardware da plataforma específica.
Não específico da plataforma: funcionalidade padrão do setor e comum a outro hardware.
Um subconjunto relativamente pequeno de firmware moderno é normalmente específico da plataforma. Grande parte do código de infraestrutura de firmware que executa tarefas comuns, como alocação de memória, expedição de drivers de firmware, manipulação de eventos e assim por diante, é o mesmo entre todos (ou a maioria) dos sistemas baseados em UEFI. Os drivers binários de firmware para essas tarefas podem ser reutilizados em computadores. Além disso, as especificações e interfaces de hardware padrão do setor permitem que drivers de firmware comuns inicializem discos rígidos, controladores USB e outros periféricos. Os drivers binários de firmware para esse hardware também podem ser reutilizados em computadores. Em resumo, os computadores podem ser inicializados com um conjunto mínimo de drivers de firmware comuns.
Reduzir o conjunto total de drivers de firmware carregados durante a inicialização pode levar a outras vantagens:
Tempo de inicialização melhorado
Coordenação reduzida do fornecedor para atualizações
Exposição reduzida a bugs
Redução da superfície de ataque
Verificação do caminho de inicialização FASR e conformidade com o núcleo seguro
Para que um sistema FASR atenda aos requisitos de proteção de firmware de computadores de núcleo seguro, ele deve ter sido inicializado no caminho de inicialização certificado. O firmware FASR facilita isso fornecendo ao sistema operacional um manifesto assinado pela Microsoft chamado manifesto FASR (medido no TPM) que contém os valores de PCR esperados para a sequência de inicialização do módulo no caminho certificado. Isso pode ser comparado com a sequência de inicialização real que ocorreu no caminho certificado. Se essas medidas corresponderem, o sistema será considerado como tendo atendido ao requisito de proteção de firmware do programa de computador de núcleo seguro. Qualquer desvio da sequência de caminho de inicialização certificada esperada resulta em medidas inesperadas sendo feitas nos PCRs (Registros de configuração de plataforma) do TPM que o sistema operacional detecta.
Além disso, o Windows só liberará segredos protegidos pelo hipervisor após a validação bem-sucedida do manifesto FASR assinado em relação às medidas registradas durante a inicialização atual. Se estiver em um caminho de inicialização ou atualização de cápsula certificado, o manifesto FASR não estiver presente, a verificação de assinatura falhar ou ocorrer uma incompatibilidade de PCR e os segredos do VSM não forem deslacrados nem migrados.
Como o firmware FASR lida com proteções de memória e SMM
Agora que um único binário assinado pela Microsoft com um conjunto mínimo de funcionalidades foi definido, ele poderá incluir as proteções de segurança de firmware fundamentais, mas ausentes, que a Microsoft está trabalhando com parceiros para colocar no mercado. O caminho de inicialização certificado deve, no mínimo, atender aos seguintes requisitos:
O código não é lido/gravado em NULL/Página 0
O código da imagem e as seções de dados são separados
As seções da imagem são alinhadas em um limite de página (4 KB)
Os dados são alocados apenas em tipos de memória de dados e o código em tipos de memória de código
As imagens de código não são carregadas do código distribuído como binários UEFI (somente os expedidores designados)
O código permanece dentro dos limites dos buffers de memória alocados com páginas de proteção em torno das alocações de página
O excedente de pilha pode ser detectado
O código não é executado a partir da pilha
A característica de DLL /NXCOMPAT é definida para habilitar proteções NX
ROMs de opção de terceiros, aplicativos UEFI e drivers UEFI geralmente não foram criados nem validados em relação a esse conjunto de requisitos. Portanto, eles não seriam executados no caminho de inicialização certificado. O caminho de inicialização personalizado pode, como opção, escolher reduzir o nível de proteções necessárias, mas esse caminho de inicialização não é considerado compatível com o computador de núcleo seguro pelo sistema operacional.
Modo de gerenciamento do sistema (SMM)
SMM é um modo de operação de processador especial na arquitetura x86. Ele apresenta um desafio único para a segurança do sistema, pois o código executado no ambiente SMM é opaco para o sistema operacional e normalmente é executado no nível de privilégio mais alto (às vezes chamado de "Anel -2") de qualquer software no processador host. Após a entrada, o SMM configura seu próprio ambiente, definindo a tabela de páginas, a tabela de expedição de interrupção (IDT) e outras estruturas do sistema. O SMM representa uma superfície de ataque significativa que pode ser usada por código mal-intencionado para comprometer ou contornar as proteções do sistema operacional habilitadas por meio da VBS (Segurança baseada em virtualização). Para ajudar a reduzir o perigo representado pelo SMM, a funcionalidade no SMM pode ser conceitualmente dividida na infraestrutura principal do SMM e nos drivers do SMM da seguinte maneira:
Núcleo do SMM: código comum a todas as implementações do SMM que executam responsabilidades de arquitetura e infraestrutura
Drivers SMM: código escrito para realizar uma tarefa específica da plataforma no SMM
Alguns momentos-chave no ciclo de vida do SMM são os seguintes:
Quando a base (ou núcleo) do SMM é estabelecida – o IPL (Carregamento inicial do programa) do SMM
Quando os drivers SMM são carregados – chamado de expedição do driver SMM
Quando ocorre a entrada no SMM – por meio de uma SMI (Interrupção de gerenciamento do sistema)
Carregamento inicial do programa (IPL) do SMM
A CPU tem recursos especiais que concedem ao código SMM seu alto privilégio e ajudam a protegê-lo. Por exemplo, um mecanismo é definido para entrar no SMM por meio de eventos de software ou hardware, uma instrução de CPU é usada para retornar do SMM e vários registros são definidos para controlar o acesso e bloquear a configuração do SMM. Muitos desses registros de controle são configurados pelo código IPL do SMM para restringir o acesso à área de memória em que o código e os dados do SMM são armazenados (chamado de RAM de gerenciamento do sistema ou SMRAM).
Como a área SMRAM está na memória principal (DRAM), ela não pode ser estabelecida, até que a DRAM seja habilitada durante a inicialização. Os procedimentos de habilitação de DRAM variam de acordo com o fornecedor de silício, mas alguns megabytes de código podem ser executados diretamente do cache LLC da CPU (incluindo o código que inicializa a DRAM) antes que a memória principal esteja disponível.
O firmware FASR traz o ponto IPL do SMM mais cedo na inicialização do que a maioria dos outros sistemas. Isso reduz a oportunidade que um invasor tem de minar esse processo e assumir o controle do sistema antes que o SMM seja configurado. Para entender melhor essa e outras melhorias feitas no SMM no firmware FASR, precisamos saber mais sobre o processo de inicialização do firmware.
Inicialização de PI (Inicializações de plataforma) no firmware UEFI
O firmware de computador moderno é construído em torno de muitas especificações. A especificação UEFI define a interface entre um sistema operacional compatível com UEFI, como o Windows, e o firmware no dispositivo. Outra especificação chamada Especificação da PI (Inicialização da plataforma) define a maneira como os drivers de firmware são criados e detalha o próprio processo de inicialização. Em um alto nível, a Especificação UEFI pode ser considerada como uma das padronizações que permite que uma única imagem do Windows funcione com tantos dispositivos diferentes, e a Especificação da PI pode ser considerada como uma das padronizações que permite que tantas imagens de firmware de diferentes fornecedores de hardware trabalhem juntas. As duas especificações são mantidas pelo Fórum UEFI.
A especificação da PI define as fases de inicialização e quais drivers são gravados nas fases de inicialização. Durante a inicialização do firmware, cada fase passa para a próxima e, na maioria dos casos, os drivers da entrega de fase não são mais usados e apenas dados importantes são passados para a próxima fase para que ela possa continuar o processo de inicialização. Essas fases de inicialização podem ser resumidas da seguinte maneira:
SEC – Obtenha controle no vetor de redefinição da CPU e faça a transição do assembly para o código C para carregar o PEI
PEI – Inicialize o estado do sistema para carregar o DXE e inicializar a DRAM
DXE – Execute a inicialização restante do sistema, o que inclui fornecer o suporte que o BDS precisa para carregar um sistema operacional
BDS – Descubra a opção de inicialização para a inicialização atual (por exemplo, carregador de inicialização do sistema operacional) e tente inicializar essa opção
SO - O kernel do sistema operacional
Protegendo o IPL (Carregamento inicial do programa) do SMM
O firmware tradicional compatível com a especificação da PI UEFI carrega o IPL do SMM na fase de inicialização DXE. O firmware FASR carrega o IPL do SMM na fase de inicialização do PEI. A TCB (Base de computação confiável) de um sistema é o conjunto total de mecanismos de proteção que o protegem, incluindo hardware, firmware e software. Ao mover o IPL do SMM de DXE para PEI, toda a fase DXE (que é um ambiente maior e mais rico que o PEI) é removida do TCB. O diagrama a seguir mostra o IPL do SMM movido anteriormente no processo de inicialização UEFI.
O código PEI e DXE é executado no anel 0 e não persiste (com poucas exceções) no sistema operacional. O código SMM é executado com um privilégio mais alto do que o anel 0 (e o hipervisor) e persiste no sistema operacional, portanto, não permitir que uma vulnerabilidade DXE afete o estabelecimento do SMM reduz a superfície geral de ataque do sistema. Além disso, como o SMM é iniciado anteriormente no processo de inicialização, os bits de bloqueio definidos para ajudar a proteger o SMM podem ser ativados no início da inicialização, minimizando ainda mais a janela de um invasor para comprometer o SMM.
Protegendo o processo de expedição do driver SMM
Dentro da especificação da PI, dois modos SMM são definidos: MM tradicional e MM autônomo. O MM tradicional é equivalente ao modelo de software SMM historicamente usado em firmware compatível com PI, que constitui a maioria dos firmwares UEFI do setor. O MM autônomo é um modo relativamente novo que revisa o modelo histórico para melhorar a segurança do ambiente SMM e evitar erros comuns cometidos em implementações de MM tradicionais que levaram a vários desafios de portabilidade e segurança ao longo dos anos.
O firmware FASR opera exclusivamente no modo MM autônomo. Isso permite que o firmware FASR siga uma abordagem disciplinada para a execução de software no SMM. Muitas vulnerabilidades baseadas em SMM hoje são devidas a más práticas permitidas no código SMM no MM tradicional que podem ser simplesmente removidas no MM autônomo. Em um alto nível, isso acontece porque, no modelo MM tradicional, um driver SMM é expedido duas vezes, uma vez pelo expedidor DXE no anel 0 e novamente pelo expedidor SMM no SMM. Isso oferece ampla oportunidade para o código do driver executado no ambiente DXE armazenar em cache ponteiros para recursos fora da SMRAM que eles não devem acessar após o retorno do ponto de entrada. Os ataques que dependem do código SMM para chamar o código fora do SMM geralmente são chamados de "ataques de chamada SMM".
Protegendo a entrada no SMM
Os dados são passados para um manipulador SMI por meio de uma estrutura chamada "buffer de comunicação". O manipulador SMI é responsável por validar se os dados atendem a determinados requisitos em seu ponto de entrada. A WSMT (Windows SMM Security Mitigation Table, Tabela de Mitigação de Segurança do SMM do Windows) é um mecanismo usado para ajudar a mitigar a ameaça que os manipuladores SMI não verificados representam para a segurança baseada em virtualização no sistema operacional. A Microsoft contribuiu com código para o projeto TianoCore para melhorar a validação do buffer de comunicação. Além de aplicar essas duas técnicas, o código FASR também implementa proteções rígidas de acesso à memória, permitindo que o código SMM acesse apenas intervalos de memória explicitamente permitidos.
Supervisor do modo de gerenciamento (Supervisor MM)
O código principal do SMM é comum e compartilhado com pouca ou nenhuma alteração entre os sistemas. A superfície de ataque imposta pelo SMM pode ser bastante reduzida com a introdução da separação de privilégios no ambiente do SMM. Por esse motivo, o firmware FASR inclui um supervisor SMM que é executado em MM autônomo. Isso resulta em um ambiente SMM bem definido com um TCB mínimo que tem níveis de privilégio impostos desde a criação. O Supervisor MM impõe restrições aos acessos à porta de E/S, acessos ao MSR (Registro específico do modelo), acesso ao MMIO, acesso ao estado de salvamento da CPU e instruções permitidas no ambiente SMM. Uma política de Supervisor de SMM é usada para configurar os detalhes exatos de quais recursos de hardware restringir, e esses detalhes exatos estão sujeitos a alterações por geração de silício.
A política foi recentemente transferida para uma abordagem de negação por padrão que reduz significativamente os recursos de hardware disponíveis para código fora do Supervisor do SMM. Esse supervisor opera sem uma dependência de hardware em nenhum recurso de hardware não comumente encontrado em computadores modernos.
O MM Supervisor é usado no FASR, é de código aberto e está disponível no Repositório do supervisor do projeto Mu MM.
Conformidade do sistema FASR com os requisitos de computador de núcleo seguro
A tabela a seguir indica os amplos pilares ou metas de segurança dos computadores de núcleo seguro e como os sistemas FASR sendo inicializados no caminho certificado podem atender aos requisitos dos computadores de núcleo seguro:
| Benefícios de segurança | Recursos de segurança em computadores de núcleo seguro |
|---|---|
| Criar uma raiz de confiança com suporte de hardware | Inicialização Segura |
| Trusted Platform Module 2.0 | |
| Proteção de Acesso Direto à Memória (DMA) | |
| Defenda-se contra ataques de nível de firmware (confira a nota abaixo) | Inicialização segura do System Guard (D-RTM) ou S-RTM (FASR FW) |
| Isolamento do SMM (Modo de gerenciamento do sistema) ou MM autônomo com supervisor de MM (FASR FW) | |
| Proteger o sistema operacional contra a execução de código não verificado | Integridade da memória (também conhecida como HVCI) |
| Fornece proteção e verificação de identidade avançadas | Windows Hello |
| Proteja dados críticos em caso de perda ou roubo de dispositivos | Criptografia de BitLocker |
Se o sistema não tiver recursos avançados de segurança para compatibilidade com D-RTM, os requisitos de proteção de firmware poderão ser atendidos usando uma combinação de S-RTM e MM autônomo com Supervisor de MM, os dois oferecidos pelo firmware FASR.
Resumo
Esses são alguns dos investimentos que a Microsoft fez para lidar com o crescente número de ataques de firmware que prevalecem em todo o setor hoje. Ao usar código aberto para essas mudanças, estamos capacitando nossos parceiros a usar alguns desses benefícios de segurança que, por sua vez, beneficiarão o ecossistema mais amplo e a indústria em geral.
O principal objetivo da iniciativa de computador de núcleo seguro é ajudar a garantir que os clientes tenham acesso a alguns dos recursos de segurança mais avançados disponíveis para computadores com Windows. Com algumas dessas alterações de firmware, estamos um passo mais perto de atingir esse objetivo e atualizamos os requisitos de proteção de firmware de computadores de núcleo seguro para refletir essa inclusão. Saiba mais sobre computadores de núcleo seguro aqui.