gdanna.blogg.se

1. Intel to spectre meltdown chip flaw software#
2. Intel to spectre meltdown chip flaw code#
3. Intel to spectre meltdown chip flaw windows#

Intel to spectre meltdown chip flaw software#

Intel has also been publicly reluctant to agree with the disabling of HT when others have called for it with the discovery of some previous CPU flaws, but in its paper, the company stated that disabling HT altogether may be warranted as protection against MDS attacks.ĭespite all of these drawbacks, Intel did mention in the white paper that these software mitigations are highly recommended, despite the vulnerabilities being classified only low to medium severity. Intel itself seems to be moving away from Hyper Threading lately on some of its best CPUs, even in the face of AMD competition with both higher number of cores and simultaneous multithreading (SMT) support at similar price points. It seems that with every other speculative execution attack, Intel’s Hyper Threading becomes either less secure or slower. Threads from different security domains will simply become idle (thus turning into wasted processing power). The threads will need a higher level of isolation between each other, and they will not be able to run processes from different security domains anymore. The company admitted in its white paper that the software mitigations will have a significant effect on how HT works. Intel Recommends Disabling Hyper Threading How large or small, it remains to be seen, but chances are it could be on the significant side. Adding such a significant step in the processing software will most likely lead to a performance loss.

Intel to spectre meltdown chip flaw windows#

The solution will involve clearing microarchitectural buffers when switching to software that is not trusted by the previous software.įor instance, every time a processor would switch from one third-party app to another, from a Windows process to a third-party app, or even from less trusted Windows processes to more trusted ones, the buffers would have to be cleared or overwritten.

Intel believes that in order to protect users against this speculative execution issue, Microsoft and other operating system vendors, hypervisor vendors, as well as Intel itself will need to implement significant changes in their software. Significant Changes to Operating Systems, Core Software Are Required CVE-2019-11091 Microarchitectural Data Sampling Uncacheable Memory (MDSUM).

Intel to spectre meltdown chip flaw code#

The Microarchitectural Data Sampling (MDS) issue is a speculative execution side-channel attack that may allow malicious actors to locally execute code in order to extract sensitive data that would otherwise by protected by Intel processors’ architectural mechanisms.Īccording to Intel, four CVEs were assigned to this flaw in Intel’s processors, including: Microarchitectural Data Sampling in Intel Chips The vulnerability affects most of the company’s processor SKUs, except the 8th and 9th generation chips, which Intel said includes hardware mitigations against this flaw. Add in that 1 or their two attacks is via SMT, I think ASi is probably pretty safe from this.Intel unveiled yet another speculative execution side-channel flaw in its processors. I won't say this attack is impossible on Apple Silicon but as you say, it would be more difficult-probably much more difficult. That complexity isn't there in the M1 or any Arm RISC system. I was reading as much of the white paper as I could understand without doing further research and my conclusion is that even if the M1 is using a micro-op cache, the authors are using the x86 ISA complexity as a way of detecting micro-op cache hits and misses. This is also one of the main reasons M1 has such amazing single threaded performance since it isn’t limited by the decoder. The x86 ISA should die already. Micro-ops are fixed length and shouldn’t require much caching unlike Intel/AMD. The memory model of ARM makes these types of attacks more difficult. Since Apple's ARM SoC cores don't use SMT, it looks like they are safe from this. Someone with more knowledge of Arm CPU Architecture should chime in.Įdit: And apparently SMT (also known as hyper-threading) is involved. In general RISC CPUs have much simpler decoding so it is possible that micro-ops aren't cached at all or the cache structure is much simpler. The caching of micro-ops is the source of this vulnerability.

I know that Apple's Arm CPUs use micro-ops but I don't know anything about if or how they are cached.