Segundo os pesquisadores: No momento, não está claro se os processadores ARM e AMD também são afetados pelo Meltdown.
Janghou
11
Há um exemplo de que você pode roubar uma senha com Javascript em um navegador (Chrome / Firefox).
Janghou
4
@ alex2003super: Não surte. Embora a escala dos dispositivos afetados seja impressionante, as chances de você ser realmente afetado por esse problema de maneira real são bastante baixas. E mesmo que não fossem, surtar não ajudaria. :)
Lightness Races com Monica
11
Parece que eles não são vulneráveis, aqui está um artigo recente sobre o assunto raspberrypi.org/blog/…
Segundo o próprio ARM , os núcleos do processador usados em todos os modelos anteriores ao Pi 4 não são vulneráveis .
A maioria dos processadores Arm não é afetada por nenhuma variação desse mecanismo de especulação de canal lateral. Uma lista definitiva do pequeno subconjunto de processadores projetados pela Arm que são suscetíveis pode ser encontrada abaixo. [veja o link para a tabela]
Os núcleos do processador usados pelos Pis mais antigos são:
Nenhum dos núcleos acima está listado como vulnerável a qualquer versão do ataque (eles não estão listados, de fato, porque não há vulnerabilidade conhecida para esses ataques).
O Raspberry Pi 4 usa o Cortex-A72 , listado como vulnerável às variantes 1, 2, 3a e 4. Conforme indicado em O Raspberry Pi 4 é vulnerável às explorações do Spectre? , Raspbian contém atenuações de software para essas vulnerabilidades, portanto, o risco de exploração deve ser baixo. Outros sistemas operacionais podem não conter atenuações apropriadas e, embora o ARM diga que foi lançada uma atenuação de hardware para o Cortex-A72, não está claro se isso foi aplicado ao Pi 4.
Observe que as variantes 1 e 2 (CVE-2017-5753 e CVE-2017-5715) são conhecidas como Spectre e as variantes 3 (CVE-2017-5754) e 3a (um ataque relacionado investigado pelo ARM) são chamadas de fusão . Portanto, acredita-se que nenhum dos dispositivos Raspberry Pi anteriores ao Pi 4 seja vulnerável ao Spectre ou ao Meltdown.
Gostaria de saber se as alterações no kernel do Linux necessárias em outras arquiteturas serão enviadas para as versões do Linux que são executadas no Raspberry Pi? Supostamente, essas alterações desacelerarão o sistema, portanto, talvez o RP seja afetado, mesmo que os patches não sejam necessários.
Bobby Durrett
4
O patch do kernel detecta em qual processador está sendo executado e se desabilita automaticamente se não for um modelo afetado. Além disso, os kernels do Raspberry Pi (e a maioria dos outros computadores de placa única) são criados especificamente para o hardware disponível, e não há motivo para os mantenedores incluirem ou habilitarem o patch em questão.
Perkins
11
@BobbyDurrett, as alterações do Meltdown no kernel estão na seção específica do x86 da base de código. As alterações relacionadas ao espectro estão por todo o lado, mas a maioria delas está em seções específicas do processador ou são tratadas pelo compilador. Alguns bits, como alterações estruturais no código de rede, podem vazar para o Pi, mas a maioria não.
Mark
Obrigado pelos comentários. É interessante pensar sobre quais partes do código do kernel do Linux são específicas do processador. Eu acho que com um sistema operacional que roda em muitos tipos diferentes de CPUs, você precisa fazer um bom trabalho ao dividir o código específico de cada processador.
Bobby Durrett
22
O Pi (todas as versões) não é vulnerável.
Spectre e Meltdown requerem execução fora de ordem. O Cortex-A7 usado no início do Pi 2 e o Cortex A53 usado no posterior Pi 2 e o Pi 3 são uma arquitetura estritamente em ordem. O ARM11 usado no Pi 1 está parcialmente fora de ordem, mas não de uma maneira que permita que Spectre ou Meltdown funcionem.
O ARM confirma isso : apenas um subconjunto muito limitado de processadores ARM possui hardware que os torna vulneráveis ao Spectre, um subconjunto ainda mais limitado é vulnerável ao Meltdown, e acredita-se que todos eles permitem mitigar a ameaça.
Eu gostaria de oferecer minha opinião diferente sobre isso.
Sobre o Meltdown, é uma vulnerabilidade muito específica em alguns processadores; portanto, se o ARM diz que a CPU no Raspberry Pi não é vulnerável, provavelmente pode ser confiável.
No entanto, o Spectre é uma vulnerabilidade mais geral. Até agora, apenas duas variantes foram demonstradas, mas tenho certeza de que existem mais variantes. A falha na CPU é que o estado do preditor de ramificação não é liberado ao fazer uma alternância de contexto, e esse estado do preditor de ramificação é indexado pelos bits de ordem inferior do endereço de instrução da ramificação e nem é marcado. Portanto, você pode ter duas ramificações compartilhando o mesmo estado preditor de ramificação, mesmo através dos limites do processo.
Estou muito confiante de que a CPU em todos os modelos Raspberry Pi é semelhante a praticamente todas as outras CPUs por aí, em que o preditor de ramificação é apenas uma grande variedade de contadores de saturação de 2 bits (tomada forte, tomada fraca, fraca não tomada, forte Não pego). O índice para esta matriz são os bits de ordem inferior do endereço de instrução de ramificação, e não há tag, e esse estado do preditor nunca é liberado.
Agora, se duas ramificações compartilham o mesmo estado preditivo, você pode medir o caminho que uma ramificação específica tomou no passado muito recente. O vazamento de informações do Spectre está lá! Se você puder acionar o navegador de forma confiável para executar alguma ramificação de código em sua senha a partir do JavaScript e medir em que direção as ramificações foram, você poderá realmente extrair a senha. Agora, este é um exemplo extremo: ninguém em sã consciência iria ramificar cada bit da sua senha de uma maneira que possa ser acionada a partir do JavaScript, mas isso demonstra o problema.
Não acredite em tudo o que a ARM diz. O que o ARM significa é provavelmente que as explorações que o Google desenvolveu não funcionam nessas CPUs ARM. Isso não significa que eles seriam invulneráveis para Spectre. Algum outro tipo de exploração pode funcionar.
Consulte esta pergunta: https://security.stackexchange.com/questions/176678/is-branch-predictor-flush-instruction-a-complete-spectre-fix e compreenda as implicações de sua resposta. Um código JavaScript não autorizado em execução no seu navegador pode, devido à Specter medir de que maneira outras ramificações do processo foram executadas. Mesmo uma instrução de liberação do preditor de ramificação não corrigirá esse problema desonesto de JavaScript, a menos que o navegador libere ativamente o preditor de ramificação antes de executar o código não confiável.
O Spectre estará conosco por um tempo muito, muito longo, pois o preditor de ramificação usando 14 bits como índice não é marcado com os 18 bits restantes de um espaço de endereço de 32 bits, porque exigiria 20 bits (contador de saturação de 2 bits). , Tag de 18 bits) em vez de apenas 2 bits. Isso multiplicaria o tamanho do preditor de ramificação por dez! Eu estou esperando que os fabricantes de CPU adicionem uma instrução de liberação do preditor de ramificação que funcione mesmo no espaço do usuário sem privilégios especiais e que o kernel use-a na alternância de contexto e o espaço do usuário na execução de código JIT não confiável. Isso resolveria a maioria dos problemas de espectro na prática, mas em teoria, nem todos eles.
" Agora, se duas ramificações compartilham o mesmo estado preditivo, você pode medir o caminho que uma ramificação em particular tomou no passado muito recente. " Como você faz isso sem execução especulativa?
Peter Taylor
@PeterTaylor, essas CPUs ARM têm preditor de ramificação e, portanto, têm execução especulativa. O que eles estão perdendo é a execução fora de ordem.
juhist
Eles estão documentados para ter busca especulativa de instruções, mas isso não é execução especulativa. É um ponto justo que ainda seja possível usá-lo como um oráculo.
Peter Taylor
Mesmo a busca especulativa pode ser suficiente, pois haverá uma diferença de latência menor, mas mensurável.
juhist
O Linux já estava adicionando randomização de endereço do kernel; você não pode prever o endereço de uma filial.
Respostas:
Segundo o próprio ARM , os núcleos do processador usados em todos os modelos anteriores ao Pi 4 não são vulneráveis .
Os núcleos do processador usados pelos Pis mais antigos são:
Pi 1 e Zero (W) : ARM11
Pi 2 V1 : ARM Cortex-A7
Pi 2 V1.2 e Pi 3 : ARM Cortex-A53
Nenhum dos núcleos acima está listado como vulnerável a qualquer versão do ataque (eles não estão listados, de fato, porque não há vulnerabilidade conhecida para esses ataques).
O Raspberry Pi 4 usa o Cortex-A72 , listado como vulnerável às variantes 1, 2, 3a e 4. Conforme indicado em O Raspberry Pi 4 é vulnerável às explorações do Spectre? , Raspbian contém atenuações de software para essas vulnerabilidades, portanto, o risco de exploração deve ser baixo. Outros sistemas operacionais podem não conter atenuações apropriadas e, embora o ARM diga que foi lançada uma atenuação de hardware para o Cortex-A72, não está claro se isso foi aplicado ao Pi 4.
Observe que as variantes 1 e 2 (CVE-2017-5753 e CVE-2017-5715) são conhecidas como Spectre e as variantes 3 (CVE-2017-5754) e 3a (um ataque relacionado investigado pelo ARM) são chamadas de fusão . Portanto, acredita-se que nenhum dos dispositivos Raspberry Pi anteriores ao Pi 4 seja vulnerável ao Spectre ou ao Meltdown.
fonte
O Pi (todas as versões) não é vulnerável.
Spectre e Meltdown requerem execução fora de ordem. O Cortex-A7 usado no início do Pi 2 e o Cortex A53 usado no posterior Pi 2 e o Pi 3 são uma arquitetura estritamente em ordem. O ARM11 usado no Pi 1 está parcialmente fora de ordem, mas não de uma maneira que permita que Spectre ou Meltdown funcionem.
O ARM confirma isso : apenas um subconjunto muito limitado de processadores ARM possui hardware que os torna vulneráveis ao Spectre, um subconjunto ainda mais limitado é vulnerável ao Meltdown, e acredita-se que todos eles permitem mitigar a ameaça.
fonte
Eu gostaria de oferecer minha opinião diferente sobre isso.
Sobre o Meltdown, é uma vulnerabilidade muito específica em alguns processadores; portanto, se o ARM diz que a CPU no Raspberry Pi não é vulnerável, provavelmente pode ser confiável.
No entanto, o Spectre é uma vulnerabilidade mais geral. Até agora, apenas duas variantes foram demonstradas, mas tenho certeza de que existem mais variantes. A falha na CPU é que o estado do preditor de ramificação não é liberado ao fazer uma alternância de contexto, e esse estado do preditor de ramificação é indexado pelos bits de ordem inferior do endereço de instrução da ramificação e nem é marcado. Portanto, você pode ter duas ramificações compartilhando o mesmo estado preditor de ramificação, mesmo através dos limites do processo.
Estou muito confiante de que a CPU em todos os modelos Raspberry Pi é semelhante a praticamente todas as outras CPUs por aí, em que o preditor de ramificação é apenas uma grande variedade de contadores de saturação de 2 bits (tomada forte, tomada fraca, fraca não tomada, forte Não pego). O índice para esta matriz são os bits de ordem inferior do endereço de instrução de ramificação, e não há tag, e esse estado do preditor nunca é liberado.
Agora, se duas ramificações compartilham o mesmo estado preditivo, você pode medir o caminho que uma ramificação específica tomou no passado muito recente. O vazamento de informações do Spectre está lá! Se você puder acionar o navegador de forma confiável para executar alguma ramificação de código em sua senha a partir do JavaScript e medir em que direção as ramificações foram, você poderá realmente extrair a senha. Agora, este é um exemplo extremo: ninguém em sã consciência iria ramificar cada bit da sua senha de uma maneira que possa ser acionada a partir do JavaScript, mas isso demonstra o problema.
Não acredite em tudo o que a ARM diz. O que o ARM significa é provavelmente que as explorações que o Google desenvolveu não funcionam nessas CPUs ARM. Isso não significa que eles seriam invulneráveis para Spectre. Algum outro tipo de exploração pode funcionar.
Consulte esta pergunta: https://security.stackexchange.com/questions/176678/is-branch-predictor-flush-instruction-a-complete-spectre-fix e compreenda as implicações de sua resposta. Um código JavaScript não autorizado em execução no seu navegador pode, devido à Specter medir de que maneira outras ramificações do processo foram executadas. Mesmo uma instrução de liberação do preditor de ramificação não corrigirá esse problema desonesto de JavaScript, a menos que o navegador libere ativamente o preditor de ramificação antes de executar o código não confiável.
O Spectre estará conosco por um tempo muito, muito longo, pois o preditor de ramificação usando 14 bits como índice não é marcado com os 18 bits restantes de um espaço de endereço de 32 bits, porque exigiria 20 bits (contador de saturação de 2 bits). , Tag de 18 bits) em vez de apenas 2 bits. Isso multiplicaria o tamanho do preditor de ramificação por dez! Eu estou esperando que os fabricantes de CPU adicionem uma instrução de liberação do preditor de ramificação que funcione mesmo no espaço do usuário sem privilégios especiais e que o kernel use-a na alternância de contexto e o espaço do usuário na execução de código JIT não confiável. Isso resolveria a maioria dos problemas de espectro na prática, mas em teoria, nem todos eles.
fonte