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

Os chips DRAM são muito compactados. A pesquisa mostrou que os bits vizinhos podem ser trocados aleatoriamente.

Qual é a probabilidade de o bug ser acionado aleatoriamente em um chip DRAM de nível de servidor com ECC (o documento da CMU-Intel cita, por exemplo, o número 9.4x10 ^ -14 para um chip desconhecido por uma falha no período de um ano)?
Como sei se o bug foi corrigido antes de comprar memória?
O que devo fazer para combater tentativas mal-intencionadas de fazer a escalação de privilégios por exemplo, inquilinos ou usuários sem privilégios, por exemplo, no CentOS 7?

Referências:

— Deer Hunter
fonte

Como os detalhes da exploração ainda não foram embargados, não tenho certeza de que haverá muitas informações disponíveis além do que o Google já forneceu a você.

— Fkawi2

Pelo que entendi, a taxa de atualização de memória diminui drasticamente as chances de um retorno de bits bem-sucedido, e as versões mais recentes do BIOS diminuíram as taxas de atualização para tentar reduzir o risco. Portanto, atualizar o BIOS pode ser um bom primeiro passo?

— Reaces

@ fukawi2, que detalhes da exploração foram / estão embargados? O código completo das explorações de prova de conceito foi lançado com a postagem do blog.

— Marque # Seaborn

@ MarkSeaborn Eu nem me lembro agora, isso foi há 3 meses e mal consigo me lembrar do café da manhã.

— fukawi2

Respostas:

O documento da 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 teórico proposto chamado "PARA" (que pode ser semelhante a um mecanismo de mitigação existente pTRR (pseudo Target Row Refresh)) e é irrelevante para o seu pergunta, porque PARA não tem nada a ver com ECC.

Um segundo artigo 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 "guarda de banda").

O ECC transforma efetivamente a exploração do Row Hammer em um ataque do DOS. Os erros de 1bit serão corrigidos pelo ECC e, assim que um erro não corrigível de 2bit for detectado, o sistema será interrompido (assumindo o SECDED ECC).

Uma solução é comprar hardware que suporte pTRR ou TRR. Veja a publicação atual da Cisco sobre Row Hammer . Pelo menos alguns fabricantes parecem ter um desses mecanismos de mitigação incorporados em seus módulos DRAM, mas o mantêm profundamente oculto 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 agressivos de patrulha de limpeza também ajudam, mas teriam um impacto no desempenho. Mas eu não conheço nenhum hardware de servidor que realmente permita o ajuste fino desses parâmetros.

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

— Daniel
fonte

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 resposta parcial. Para notícias, siga a lista de discussão sobre discussão e discussão.

No momento, não tenho certeza de que seja possível obter informações públicas para evitar a compra de RAM vulnerável, nem prever facilmente taxas de falha no hardware existente. Os fabricantes não foram abertos com informações sobre como seus produtos são afetados. É possível testar a memória já comprada 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 na execução do software.

"As empresas de memória sem nome" tentaram pagar um suborno em troca da Passmark Software não lançar um teste de martelo de linha em sua ferramenta Memtest86.

Foi relatado que o hardware da Intel Skylake é mais vulnerável, e não menos importante , ao martelo de linha devido à adição de uma nova clflushoptinstrução. Isso já foi explorado no rowhammer.js

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

Enquanto parte da RAM ECC é menos vulnerável do que a RAM não ECC ao martelo de linha, outra RAM ECC é mais vulnerável que a RAM não ECC ( link para a pergunta no vídeo )
Mudar para uma taxa de atualização mais rápida é suficiente para impedir o martelo de linha com a maioria, mas não todo o hardware - mas nem todos os BIOS permitem alterar a taxa de atualização ( link para a pergunta no vídeo ).

Como contramedida, pode ser possível detectar ataques de martelo de linha em andamento, mas não sei se isso foi feito.

— Croad Langshan
fonte