Fasr (Redução da Superfície de Ataque de Firmware)

Em outubro de 2019, a Microsoft trabalhou em estreita colaboração com nossos parceiros OEM e Silicon para lançar PCs de núcleo seguro. Esses dispositivos apresentam hardware, firmware e software profundamente integrados para ajudar a garantir segurança aprimorada para os dispositivos, identidade e dados. Um dos principais pilares de segurança dos computadores de núcleo protegido é ajudar a oferecer proteção de firmware para dispositivos. Um recurso fundamental baseado em hardware necessário para satisfazer esse pilar é a Raiz Dinâmica de Confiança para Medida (D-RTM). No entanto, não há muitos dispositivos que oferecem D-RTM hoje devido à dependência do chipset subjacente para dar suporte a essa funcionalidade, o que impede nosso compromisso de ajudar a aumentar e manter uma barra de segurança alta 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. Para ajudar a fechar essa lacuna, a Microsoft começou a trabalhar com parceiros para superar os problemas de compatibilidade que impediram que as proteções de memória fossem aplicadas no firmware UEFI desenvolvendo um conjunto de aprimoramentos de segurança do SMM de software livre para fornecer flexibilidade adicional para os OEMs aproveitarem.

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 de computadores de núcleo protegido.

Visão geral da FASR

Para computadores de núcleo protegido 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 atestados no sistema operacional. Essa abordagem é chamada fasr (redução de superfície de ataque de firmware). Para que o firmware baseado em FASR seja dimensionado entre computadores de diferentes fornecedores, era preciso definir uma nova abordagem para o processo de inicialização de firmware.

A FASR dá suporte a dois caminhos de inicialização:

1. Caminho de inicialização certificado:

   • Somente o código confiável, assinado e integrado pela Microsoft tem permissão para ser executado.

   • A adulteração do caminho de inicialização é detectável pelo sistema operacional.

   A figura abaixo mostra o fluxo de inicialização S-RTM fasr no caminho de inicialização certificado. Esse caminho de inicialização ajuda a impedir a execução inesperada do código de firmware da plataforma. 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 fasr no caminho de inicialização certificado.

   

2. Caminho de inicialização personalizado: Todo o código de firmware da plataforma pode ser executado. Informações críticas de inicialização específicas para 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 fasr no caminho de inicialização personalizado.

   

   Um dispositivo FASR habilitado para conformidade de computador de núcleo protegido, usa como padrão o caminho de inicialização certificado, a menos que ocorra um evento que faça com que a inicialização mude 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 PC de núcleo protegido, o que significa que ele sempre será inicializado no caminho de inicialização personalizado até que seja reabilitado.

   Observe que a inicialização personalizada pode ser usada para inicializar qualquer sistema operacional ou software de terceiros, conforme suportado pelo 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 protegido.

Para entender melhor as tecnologias de segurança por trás da 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 de 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 progride. Cada conjunto de códigos verifica o próximo conjunto de código que forma uma cadeia de confiança. Quando o firmware UEFI ganha controle, ele segue o padrão de Inicialização Segura de verificar 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 buscam obter o controle o mais cedo possível no processo de inicialização antes que os recursos de segurança e os bloqueios que ajudam a proteger o sistema sejam habilitados. Quando o sistema é retirado da redefinição, o conjunto inicial de código executado deve ser ancorado em confiança. A tecnologia de verificação de hardware que atende à função para executar essa verificação antecipada de código é 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 têm raiz 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 exatamente do que o firmware executou. O Programa de Compatibilidade de Hardware do Windows exige que todos os computadores Windows 10 e Windows 11 incluam um chip chamado TPM (Trusted Platform Module). O TPM contém locais de memória chamados PCRs (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 com suporte. 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 TCG pc define a inclusão de pelo menos um banco PCR com 24 registros.

Com um TPM presente, cada componente de firmware também pode atualizar ou estender o PCR apropriado à medida que novos códigos e dados são carregados no processo de inicialização. O processo de extensão atualiza o valor pcr para ser a saída do algoritmo de hash usando o valor 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 era diferente das inicializações anteriores. Em um ambiente sensível à segurança, o sistema operacional pode ser informado do 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 redefinindo 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ático e dinâmico.

Uma Raiz Estática de Confiança para Medida (S-RTM) estabelece a confiança na redefinição do sistema e exige que a confiança seja mantida durante todo o processo de inicialização. Se a confiança for comprometida a qualquer momento no processo de inicialização, ela será irrecuperável até a redefinição do sistema. O diagrama a seguir ilustra como o S-RTM é usado no caminho de inicialização certificado.

Por outro lado, a Raiz Dinâmica de Confiança para Medida (D-RTM) confia apenas em uma pequena parte do código de firmware de inicialização de chipset inicializado, bem como em um agente de hardware usado para restabelecer a confiança dinamicamente durante a inicialização. Inicialmente, o sistema pode inicializar em código de firmware não confiável, mas, logo após a inicialização, 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 compensação entre S-RTM e D-RTM. O S-RTM não requer recursos especiais de hardware, mas exige que o software tenha uma conta melhor para o código executado durante toda a inicialização. O D-RTM requer recursos de hardware especiais, mas permite que o software seja iniciado em um estado confiável dinamicamente durante o tempo de vida do sistema.

PCs de núcleo protegido do Windows usaram um D-RTM em Inicialização Segura para permitir flexibilidade para que o amplo conjunto de fabricantes de sistemas implemente recursos e experiências exclusivos no firmware, ao mesmo tempo em que ajuda a garantir que o sistema possa alcançar um estado confiável e medido 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 poderia ser implementado em mais dispositivos devido à sua falta de dependência em 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 poderia confiar nas medidas relatadas em qualquer determinado dispositivo Windows usando S-RTM.

Aprimoramentos de segurança de firmware

Minimizar os componentes de firmware no caminho de inicialização do sistema operacional

Uma maneira de confiar em medidas S-RTM é reduzir os componentes de firmware permitidos para executar em um conjunto mínimo. Se todos os dispositivos que usam S-RTM usarem o mesmo conjunto de componentes de firmware, o sistema operacional só precisará 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 protegido quando o conjunto de firmware de inicialização é verificado para conter 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 de computador normal, vamos examinar o processo de inicialização antes e depois.

Devido à flexibilidade e ao conjunto avançado de recursos oferecidos pelo firmware de computador moderno, o código executado antes do sistema operacional resulta em uma superfície de ataque maior. 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 de plataforma específico.

• Não específico da plataforma: funcionalidade que é padrão do setor e comum a outros hardwares.

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 alocar memória, expedir drivers de firmware, lidar com eventos e assim por diante é o mesmo entre todos (ou a maioria) sistemas baseados em UEFI. Os drivers binários de firmware para essas tarefas podem ser reutilizados entre 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 entre 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 aprimorado

• Diminuição da coordenação do fornecedor para atualizações

• Redução da exposição de bugs

• Superfície de ataque reduzida

Verificação do caminho de inicialização fasr e conformidade de núcleo protegido

Para que um sistema FASR atenda aos requisitos de proteção de firmware de computadores de núcleo protegido, ele deve ter 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 PC de núcleo seguro. Qualquer desvio da sequência de caminho de inicialização certificada esperada resultará em medições inesperadas feitas nos PCRs (Registros de Configuração de Plataforma) do TPM que o sistema operacional detectará.

Além disso, o Windows só liberará segredos protegidos por hipervisor após a validação bem-sucedida do manifesto FASR assinado em relação às medidas registradas durante a inicialização atual. Se em um caminho de inicialização certificado ou uma atualização de cápsula, 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 serão não selados ou migrados.

Como o firmware fasr aborda 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 pode incluir as proteções de segurança de firmware fundamentais, mas ausentes, que a Microsoft está trabalhando com parceiros para trazer ao mercado. O caminho de inicialização certificado deve, no mínimo, atender aos seguintes requisitos:

1. O código não lê/grava em NULL/Página 0

2. O código de imagem e as seções de dados são separados

3. As seções de imagem são alinhadas em um limite de página (4 KB)

4. Os dados são alocados apenas em tipos de memória de dados e código em tipos de memória de código

5. As imagens de código não são carregadas do código distribuído como binários UEFI (somente os dispatchers designados)

6. O código permanece dentro dos limites de buffers de memória alocados com páginas de proteção em torno de alocações de página

7. O estouro de pilha pode ser detectado

8. O código não é executado da pilha

9. A característica de DLL /NXCOMPAT está definida para habilitar proteções NX

RoMs de opção de terceiros, aplicativos UEFI e drivers UEFI geralmente não foram criados ou validados em relação a esse conjunto de requisitos. Portanto, eles não seriam executados no caminho de inicialização certificado. Opcionalmente, o caminho de inicialização personalizado pode optar por diminuir 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)

O SMM é um modo operacional especial do processador na arquitetura x86. Ele apresenta um desafio exclusivo à segurança do sistema, pois o código executado no ambiente do 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 configurando a tabela de páginas, a tabela de expedição de interrupção (IDT) e outras estruturas do sistema. Consequentemente, o SMM representa uma superfície de ataque significativa que pode ser aproveitada 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 atenuar o perigo representado pelo SMM, a funcionalidade no SMM pode ser dividida conceitualmente na infraestrutura principal do SMM e nos drivers 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:

1. Quando a base do SMM (ou núcleo) é estabelecida – a IPL (carga inicial do programa) do SMM

2. Quando os drivers SMM são carregados – chamados de expedição de driver do SMM

3. Quando a entrada no SMM ocorre – por meio de uma SMI (Interrupção de Gerenciamento de Sistema)

A IPL (carga inicial do programa) 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 inserir o 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 a configuração de acesso e bloqueio 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 (chamados de RAM de Gerenciamento do Sistema ou SMRAM).

Como a área de SMRAM está na DRAM (memória principal), ela não pode ser estabelecida até que o DRAM esteja habilitado durante a inicialização. Os procedimentos de habilitação do DRAM variam de acordo com o fornecedor de silício, mas alguns megabytes de código podem ser executados diretamente do cache da CPU LLC (incluindo o código que inicializa o DRAM) antes que a memória principal esteja disponível.

O firmware fasr traz o ponto IPL do SMM anteriormente na inicialização do que a maioria dos outros sistemas. Isso reduz a oportunidade que um invasor tem de prejudicar 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 de firmware.

Inicialização de PI (inicialização de plataforma) no firmware UEFI

O firmware de computador moderno é criado com base em várias 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 pi (inicialização de plataforma) define a maneira como os drivers de firmware são criados e detalha o processo de inicialização em si. 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 de PI pode ser considerada como uma das padronizações que permite que tantas imagens de firmware de diferentes fornecedores de hardware trabalhem juntas. Ambas as especificações são mantidas pelo Fórum uefi.

A Especificação do 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 fase de entrega não são mais usados e apenas dados importantes são passados para a próxima fase para que possam continuar o processo de inicialização. As fases de inicialização podem ser resumidas da seguinte maneira:

1. SEC – Obter controle no vetor de redefinição de CPU e fazer a transição do assembly para o código C para carregar o PEI

2. PEI – Inicializar o estado do sistema para carregar o DXE e inicializar o DRAM

3. DXE – Executar a inicialização restante do sistema, o que inclui fornecer o suporte que o BDS precisa para carregar um sistema operacional

4. 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

5. SO – o kernel do sistema operacional

Protegendo a carga inicial do programa (IPL) do SMM

O firmware compatível com especificação UEFI PI tradicional carrega o IPL do SMM na fase de inicialização do DXE. O firmware FASR carrega o IPL do SMM na fase de inicialização do PEI. A TCB (Base de Computação Confiável) para um sistema é o conjunto total de mecanismos de proteção que a protegem, incluindo hardware, firmware e software. Ao mover o IPL do SMM do DXE para o PEI, toda a fase DXE (que é um ambiente muito 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 muito maior 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 de ataque geral do sistema. Além disso, como o SMM foi iniciado anteriormente no processo de inicialização, os bits de bloqueio definidos para ajudar a proteger o SMM podem ser habilitados anteriormente na inicialização, minimizando ainda mais a janela de um invasor para comprometer o SMM.

Protegendo o processo de expedição de driver do SMM

Dentro da Especificação do PI, dois modos SMM são definidos: MM tradicional e MM autônomo. O MM tradicional é equivalente ao modelo de software SMM historicamente usado no firmware compatível com PI, que constitui a maioria do firmware UEFI no setor. O MM autônomo é um modo relativamente novo que revisa o modelo histórico para melhorar a segurança do ambiente do SMM e evitar erros comuns cometidos em implementações de MM tradicionais que levaram a inúmeros 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 devido a práticas incorretas permitidas no código SMM no MM tradicional que podem simplesmente ser removidas no MM autônomo. Em um alto nível, isso acontece porque, no modelo MM tradicional, um driver SMM é despachado duas vezes, uma vez pelo dispatcher DXE no anel 0 e novamente pelo dispatcher do SMM no SMM. Isso oferece ampla oportunidade para o código de driver executado no ambiente DXE armazenar ponteiros em cache para recursos fora do SMRAM que eles não devem acessar após o retorno do ponto de entrada. Ataques que dependem do código SMM para chamar código fora do SMM geralmente são chamados de "ataques de texto explicativo do SMM".

Protegendo a entrada no SMM

Os dados são passados para um manipulador de 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 (Tabela de Mitigação de Segurança) do Windows SMM é um mecanismo usado para ajudar a atenuar a ameaça que manipuladores de SMI desmarcados representam para a Segurança baseada em virtualização no sistema operacional. A Microsoft contribuiu com o código para o projeto TianoCore para melhorar a validação do buffer de comunicação. Além de aproveitar essas duas técnicas, o código FASR também implementa proteções estritas de acesso à memória, permitindo que o código SMM acesse apenas intervalos de memória explicitamente permitidos.

Supervisor de Modo de Gerenciamento (Supervisor MM)

O código principal do SMM é comum e compartilhado com pouca ou nenhuma alteração entre sistemas. A superfície de ataque imposta pelo SMM pode ser muito reduzida introduzindo a separação de privilégios no ambiente do SMM. Por esse motivo, o firmware FASR inclui um Supervisor do 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 do MM impõe restrições aos acessos à porta de E/S, acessos msr (registro específico do modelo), acesso ao MMIO, acesso ao estado de salvamento de CPU e instruções permitidas no ambiente do SMM. Uma Política de Supervisor do 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.

Recentemente, a política fez a transição para uma abordagem negar 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 quaisquer funcionalidades de hardware normalmente não encontradas em computadores modernos.

O Supervisor mm é usado no FASR é de software livre e está disponível no Repositório supervisor do Project Mu MM.

Conformidade do sistema fasr com requisitos de pc de núcleo seguro

A tabela a seguir indica os amplos pilares de segurança ou metas de PCs de núcleo seguro e como os sistemas FASR inicializando no caminho certificado podem atingir os requisitos de computadores de núcleo seguro:

Benefícios à 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 contra DMA (Acesso Direto à Memória)
Defender contra ataques no nível do firmware (veja a observação abaixo)	System Guard Inicialização Segura (D-RTM) ou S-RTM (FASR FW)
	Isolamento do SMM (Modo de Gerenciamento do Sistema) ou MM autônomo com Supervisor 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)
Fornecer verificação e proteção avançadas de identidade	Windows Hello
Proteger dados críticos em caso de dispositivos perdidos ou roubados	Criptografia de BitLocker

Se o sistema não tiver recursos avançados de segurança para dar suporte ao 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 o Supervisor MM, ambos 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 predominantes em todo o setor hoje. Usando código de código aberto para essas alterações, estamos capacitando nossos parceiros a aproveitar alguns desses benefícios de segurança que, por sua vez, beneficiarão o ecossistema e a indústria mais amplos em geral.

O objetivo principal da iniciativa pc de núcleo protegido é ajudar a garantir que os clientes tenham acesso a alguns dos recursos de segurança mais avançados disponíveis para computadores Windows. Com algumas dessas alterações de firmware, estamos um passo mais perto de atingir essa meta e atualizamos os requisitos de proteção de firmware de computadores de núcleo protegido para refletir essa inclusão. Saiba mais sobre computadores de núcleo protegido aqui.