O que é o bug DRAM Rowhammer e como devo tratá-lo?

Question

Os chips DRAM são muito bem embalados. A pesquisa mostrou que os bits vizinhos podem ser invertidos aleatoriamente.

• Qual é a probabilidade do bug disparar aleatoriamente em um chip DRAM de classe de servidor com ECC (o Documento da CMU-Intel cita, por exemplo, o número 9.4x10 ^ -14 para um chip desconhecido para uma falha em um ano)?
• Como sei se o bug foi corrigido antes de comprar memória?
• O que devo fazer para contra tentativas maliciosas fazer escalada de privilégios por exemplo inquilinos ou usuários não privilegiados em, e. CentOS 7?

Referências:

• Bug de DRAM de martelo de linha explorado , Desbloqueia o acesso à memória física
• Invertendo os bits na memória sem acessá-los: um estudo experimental dos erros de perturbação da DRAM
• repo de PoC do Google
• Anotação do Project Zero

Answer 1

O papel CMU-Intel que você citou mostra (na página 5) que a taxa de erro depende muito do número de peça / data de fabricação do módulo DRAM e varia de 10 a 1000. Há também algumas indicações de que o problema é muito menos pronunciado nos chips fabricados recentemente (2014).

O número '9.4x10 ^ -14' que você citou foi usado no contexto de um mecanismo de mitigação proposto chamado "PARA" (que pode ser semelhante a um mecanismo de mitigação existente pTRR (pseudo Target Row Refresh)) e é irrelevante para a sua pergunta, porque PARA não tem nada a ver com ECC.

Um segundo documento da CMU-Intel (página 10) menciona os efeitos de diferentes algoritmos ECC na redução de erros (fator 10 ^ 2 a 10 ^ 5, possivelmente muito mais com testes sofisticados de memória e "bandagem de guarda").

O ECC transforma efetivamente o exploit Row Hammer em um ataque DOS. Erros de 1 bit serão corrigidos pelo ECC, e assim que um erro de 2 bits não corrigível for detectado, o sistema parará (assumindo o ECC do SECDED).

Uma solução é comprar hardware que suporte pTRR ou TRR. Veja atual postagem no blog da Cisco sobre a Row Hammer . Pelo menos alguns fabricantes parecem ter um desses mecanismos de mitigação embutidos em seus módulos DRAM, mas permanecem profundamente escondidos em suas especificações. Para responder à sua pergunta, pergunte ao fornecedor.

Taxas de atualização mais rápidas (32ms em vez de 64ms) e intervalos de limpeza agressivos também ajudam, mas causam impacto no desempenho. Mas eu não conheço nenhum hardware de servidor que permita realmente ajustar esses parâmetros.

Eu acho que não há muito o que você pode fazer no lado do sistema operacional, exceto encerrar processos suspeitos com alto uso constante da cpu e altas falhas de cache.

    

Answer 2

A situação ainda parece pouco clara, então não acho que suas perguntas possam ser respondidas diretamente, mas aqui estão algumas informações relativamente recentes como uma resposta parcial. Para notícias, siga a lista de discussão rowhammer-discuss .

Não tenho certeza se é possível, no momento, com informações públicas, evitar a compra de RAM vulnerável, nem prever facilmente as taxas de falhas no hardware existente. Os fabricantes não estão abertos com informações sobre como seus produtos são afetados. É possível testar a memória já adquirida usando ferramentas de software, mas você deve estar ciente de que a execução dessas ferramentas por períodos significativos (horas) pode degradar permanentemente a RAM e causar falhas no software em execução.

"Empresas de memória sem nome" declaradamente tentou pagar um suborno em troca da Passmark Software não liberar um teste de rowhammer em sua ferramenta Memtest86.

O hardware do Intel Skylake foi relatado como mais vulnerável, não menos , para rowhammer por causa da adição da adição de uma nova instrução clflushopt . Isso já foi já foi explorado em rowhammer.js

Daniel Gruss responde a algumas perguntas aqui sobre mitigação a partir de dezembro de 2015 (coautor do artigo do rowhammer.js ) em esta conversa :

1. Enquanto alguma RAM ECC é menos vulnerável que RAM não-ECC a rowhammer, outra RAM ECC é mais vulnerável que RAM não-ECC ( link para questionar em vídeo )
2. Mudar para uma taxa de atualização mais rápida é suficiente para impedir o rowhammer com a maioria dos hardware, mas não com todos - mas nem todos os BIOS permitem alterar a taxa de atualização ( link para questionar em vídeo ).

Como medida preventiva, pode ser possível detectar ataques de rowhammer em andamento, mas não sei o que foi feito.