São coisas deste tipo que me fazem pensar que a segurança, seja ela cibernética ou não, é uma ilusão.
a marca amd é mais seguro?
Algumas destas falhas de execução especulativa também afetam a AMD, no momento não existe nenhum processador no mercado que seja 100% seguro.
mas é mais seguro, certo?
Eu diria que é menos pior, seguro não é.
O que vocês acham da Bitdefender?
Se eu tenho dual boot windows/linux meu processador fica vulnerável?
Caso ele tiver a falha é claro
Olá @anon48453804 poderia fazer uma checagem em seu sistema para ver como estão os CVES no seu processador, aqui rodei e deu muito VULNERABLE com o kernel 5.2.8-arch1-1.
Vá para a etapa de verificar correções no Linux, a parte referente somente ao arch está tudo correto, gostaria que fizesse o teste pois talvez o microcode da CPU no meu arch não esteja atualizado, no Fedora aparentemente está tudo ok, fiquei encucado pois a nova versão do Hardinfo que tem a aba security mostrou daí resolvi verificar.
Agradeço desde já a atenção.
Não tem nada a ver com o S.O (Windows e Linux) o processador é quem contém as vulnerabilidades, vai precisar atualizar a Bios, efetuar as atualizações do Windows Update, no Linux também vai precisar manter o kernel e os programas atualizados.
Meus resultados foram iguais aos do artigo. Não fiz nada de especial, minha instalação é bem vanilla.
Pois é, eu fiz a verificação com o script spectre-meltdown-checker e obtive os resultados acima, o microcode aparece como a última versão, porém o script não o detecta, já no fedora o mesmo teste mostra todos CVES ok, mostrando somente as vulnerabilidades do SMT que não estão desabilitadas pois isso faz o desempenho cair pela metade já que vai desabilitar o Hiper Threading fazendo o processador funcionar somente com 2 núcleos sem as threads, mas se eu passar nosmt no grub o sistema fica 100% sem vulnerabilidades “em teoria”.
Aqui o report do hardinfo no arch(EndeavourOS)
Aqui no fedora normal sem desabilitar SMT
E aqui com o SMT desabilitado somente para teste.
Era mais por curiosidade mesmo.
Pode ser alguma incompatibilidade do script, o Arch Linux normalmente não faz modificações nos pacotes, mas outras distribuições costumam fazer, então se o script foi feito para uma distribuição específica pode não funcionar corretamente no Arch Linux.
Ainda vou tentar descobrir o que ocorre no arch (São 7 CVES em vermelho como mostrado no primeiro screenshot como VULNERABLE), no debian buster rodando em uma vm os resultados são os mesmos do fedora, estariam compilando o kernel do arch sem os devidos patches de segurança? Creio que não seria o mais correto pois com os patches o desempenho é praticamente o mesmo, fiz alguns benchmarks com o hardinfo, e a única diferença gritante que ocorre é desabilitando o SMT pois o desempenho cai pela metade, tanto de memória quanto em multi-threading devido a falta das threads no processador…
Na vdd não, vc pode formatar e instalar o Windows do site da Microsoft. Com isso, retira qualquer “bloqueio” em relação a fabricante e vc pode instalar qualquer update.
Não resolve o problema, os drives para notebooks são personalizados, e dependem da fabricante, os drives puros da intel não funcionam
Isso aí é conversa das fabricantes. Antes não conseguia instalar o último driver da Intel, tinha q usar o de 2017. Formatei, exclui a partição da fabricante, e estou usando o mais recente de agosto de 2019, com todas as correções.
Mas uma pergunta bem simples: Após a aplicação do patch, existe perda no desempenho?
Vou experimentar isso