Processador Vulnerabilidade MeltDown / Spectre (aka Kaiser bug)

Dúvido que se acabe com o x86 pelo menos nos próximos anos longos anos, muito longos anos, mas basta perceber a evolução que tem existido do lado dos arm para perceber que é preciso fazer alguma coisa
 
godevskii disse:
IMO não faz sentido nenhum, mesmo que isso acontecesse ias ver que depois iam descobrir outras vulnerabilidades por outros métodos etc... O que fazia sentido era nunca terem feito backdoors agora que a porta foi aberta não tem fim, a solução é repensar a arquitectura futura, se calhar o x86 está demasiado velho para andar a ser remendado como se fosse a camara de um peneu...
Clicar para expandir...

Isto não tem qualquer relação com backdoors e SMT é usado noutras arquitecturas (Power9, SPARC, etc), que sofrem de alguns destes problemas.

Não sei se no futuro, para algumas gerações de processadores, não vamos ver SMT desligado por default em Sistemas operativos para servidores (RHEL, Windows Server, etc). Ou pelo menos, ser severamente desaconselhado em alguns usos (Virtualização, etc).
O OpenBSD já faz isso, mas não tem tantos recursos. Eles próprios admitem que para fazer face a todos estes problemas, é preciso dar a volta a muito do código actual.
 
Tem indirectamente, porque o microcode foi feito em parte para poder traduzir algumas IS para o HW actual, e é daí que deriva o acesso à memória.

Mas claro que eles vão tentar mitigar por onde é mais fácil 1º que é reduzir o uso de SMT, mas lembra-te que isto das vulnerabilidades não começou com SMT...
 
O que o Torvalds disse é a realidade, HT da Intel deve continuar a existir e vir desabilitada default, quando ativas levas com um WARNING e ativas se quiseres, ou seja tens 100% de cpu se quiseres e estiveres disposto aos "riscos" ou então ficas com 50% safe.

Na AMD parece que isso não acontece "AMD systems though still didn't appear impacted." de qualquer forma podem optar pela mesma solução
 
2_kamikaze_2 disse:
Dúvido que se acabe com o x86 pelo menos nos próximos anos longos anos, muito longos anos, mas basta perceber a evolução que tem existido do lado dos arm para perceber que é preciso fazer alguma coisa
Clicar para expandir...

Como "entusiasta" e admirador de tecnologia (como todos nós), é um dos meus "sonhos" ver isso acontecer :) E eles (arm) andam a ficar cada vez mais poderosos! :)
 
O problema é que os riscos de segurança do SMT são muito grandes, e as soluções que se estão a apresentar têm a mesma performance que desligar o SMT. Quando se chega a este nível, ele vir off por defeito é o que faz sentido.

E quando digo remover, foi nesse sentido. Mas mais importante que tudo, era repensar o sistema todo de SMT/HT. A Intel sabia bem dos riscos, porque recebeu várias análises antes de ter enveredado por este caminho. Devia era ter logo revisto o desenho, por forma a minimizar isto, mas decidiu a saída fácil: é mais fácil tentar esconder e lucrar ao máximo. Agora... Sofrem todos.
 
Não se esqueçam que há processadores prestes a sair, em que alguns dos problemas estão resolvidos por hardware e em futuro hardware, terão mais bugs resolvidos por hardware. Além disso, a Intel prometeu lançar microcode de 3 em 3 meses, devido a estes problemas.
Isto é, em futuras gerações, a resolução destes problemas não passa apenas pelos Sistemas Operativos, onde o impacto na performance é maior.
Agora falta ver, se o problemas continuam a aparecer e isto se torna um poço sem fundo.

Nesta altura, acho que o maior problema é nas gerações actuais e passadas, especialmente em servidores.
No futuro, a coisa talvez se resolva melhor via hardware/microcode.
 
Na minha opinião em teoria o SMT devia vir off por defeito apenas nas versões servidor e nos processadores com falhas demonstraveis.
Ou seja na prática SMT deve vir ON, e quem instala em servidores intel com serviços que os tornem expostos a código de terceiros deve compilar o seu kernel e desligar o SMT, entre outras opções de segurança. No fim o que o Linus quer fazer.
 
A Microsoft lançou novo Microcode da Intel, no Windows 10 1809 e Windows 2019, mas só para alguns processadores. Broadwell (só versões servidor), skylake, kaby lake e coffee lake.

O microcode é para o Spectre 3a, 4 e L1TF.

Summary

Intel recently announced that they have completed software validations and have started to release new microcode for current CPU platforms in reaction to the following threats:

  • Spectre Variant 3a (CVE-2018-3640: "Rogue System Register Read (RSRE)")
  • Spectre Variant 4 (CVE-2018-3639: "Speculative Store Bypass (SSB)")
  • L1TF (CVE-2018-3620, CVE-2018-3646: "L1 Terminal Fault")
This new release includes a microcode update from Intel for the following CPUs.

Important Install this update for the listed processors only.
Clicar para expandir...

https://support.microsoft.com/en-us/help/4465065/kb4465065-intel-microcode-updates

A mitigação para o Spectre 3a e L1TF está activa por default, mas no Spectre 4 não vem activo por default (devido às perdas de performance?). Tem que se alterar o registry, para activar a mitigação para o Spectre 4.

https://support.microsoft.com/en-us...ive-execution-side-channel-vulnerabilities-in
 
Quem trabalha com HW ou em soluções de desenvolvimento de appliances isto é um rombo em termos de prejuízo €€€€€€ que é capaz de comer uma boa parte dos recursos da empresa. A intel e os outros fabricantes responsabilizam-se por isso?


Penalizações em contractos, redimensionamentos e custos de aquisição de mais equipamento, quem paga isto tudo?
 
Última edição:
Estava a ler o release notes do HardenedBSD 12 e tem isto no meio:

  • Symmetric Multi-Threading (SMT) disabled by default (re-enable by setting machdep.hyperthreading_allowed to 1 in loader.conf(5)).
Clicar para expandir...
https://hardenedbsd.org/article/op/2018-12-17/stable-release-hardenedbsd-stable-12-stable-v1200058

É o segundo BSD a desabilitar SMT por default.

tonyV disse:
Um 9900k, por exemplo, que vulnerabilidades conhecidas (actualmente) apresenta?
Clicar para expandir...

Em hardware, foi implementado fixs para a variante 3 e 5. É o "CFL-R" no gráfico.

LLdI4g7.png


https://www.anandtech.com/show/13400/intel-9th-gen-core-i9-9900k-i7-9700k-i5-9600k-review/2
 
Última edição:
Já tinha visto o artigo da anand...e os comentários ao artigo sobre o HT e da "solução por hardware parcial", assim como a questão das temperaturas pela altura do "chip" (der8auer).

Offtopic: com isto e com a "falta" de frequência da AMD vou esperar até Março/Abril para ver o que aparece
 
SPOILER alert (Este ataque chama-se mesmo SPOILER....)

This security shortcoming can be potentially exploited by malicious JavaScript within a web browser tab, or malware running on a system, or rogue logged-in users, to extract passwords, keys, and other data from memory. An attacker therefore requires some kind of foothold in your machine in order to pull this off. The vulnerability, it appears, cannot be easily fixed or mitigated without significant redesign work at the silicon level.

The researchers – Saad Islam, Ahmad Moghimi, Ida Bruhns, Moritz Krebbel, Berk Gulmezoglu, Thomas Eisenbarth and Berk Sunar – have found that "a weakness in the address speculation of Intel’s proprietary implementation of the memory subsystem" reveals memory layout data, making other attacks like Rowhammer much easier to carry out.

The researchers also examined Arm and AMD processor cores, but found they did not exhibit similar behavior.

SPOILER describes a technique for discerning the relationship between virtual and physical memory by measuring the timing of speculative load and store operations, and looking for discrepancies that reveal memory layout.

"The root cause of the issue is that the memory operations execute speculatively and the processor resolves the dependency when the full physical address bits are available," said Moghimi. "Physical address bits are security sensitive information and if they are available to user space, it elevates the user to perform other micro architectural attacks."

They just don't do it all that well. "The root cause for SPOILER is a weakness in the address speculation of Intel’s proprietary implementation of the memory subsystem which directly leaks timing behavior due to physical address conflicts," the paper explains.

"Our algorithm, fills up the store buffer within the processors with addresses that have the same offset but they are in different virtual pages," said Moghimi. "Then, we issue a memory load that has the same offset similarly but from a different memory page and measure the time of the load. By iterating over a good number of virtual pages, the timing reveals information about the dependency resolution failures in multiple stages."

SPOILER, the researchers say, will make existing Rowhammer and cache attacks easier, and make JavaScript-enabled attacks more feasible – instead of taking weeks, Rowhammer could take just seconds. Moghimi said the paper describes a JavaScript-based cache prime+probe technique that can be triggered with a click to leak private data and cryptographic keys not protected from cache timing attacks.

Mitigations may prove hard to come by. "There is no software mitigation that can completely erase this problem," the researchers say. Chip architecture fixes may work, they add, but at the cost of performance.

Intel is said to have been informed of the findings on December 1, 2018. The chip maker did not immediately respond to a request for comment. The paper's release comes after the 90 day grace period that's common in the security community for responsible disclosure.

Moghimi doubts Intel has a viable response. "My personal opinion is that when it comes to the memory subsystem, it's very hard to make any changes and it's not something you can patch easily with a microcode without losing tremendous performance," he said.

"So I don't think we will see a patch for this type of attack in the next five years and that could be a reason why they haven't issued a CVE."
Clicar para expandir...

https://www.theregister.co.uk/2019/03/05/spoiler_intel_flaw/

Problema existe desdeos primeiros Core da Intel. Não parece afectar AMD e ARM. Mais uma vez, o problema está na execução especulativa.

"Ajudar" o Rowhammer e poder ser usado via Javascript, é "óptimo". :S

O ele duvidar que possa haver um fix total, nem por microcode e que não há um CVE porque ele duvida que exista uma patch, deixa-me mesmo "contente". :S
 
Inicie sessão ou registe-se para poder participar.
Back
Topo