'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign


From the above, the section dealing with AMD and ARM:
6.4 Limitations on ARM and AMD

We also tried to reproduce the Meltdown bug on severalARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.

Interesting point:
Today it is considered a bug when a cryptographic algorithm is not protected against the microarchitectural leakage introduced by the hardware optimizations. Meltdown changes the situation entirely. Meltdown shifts the granularity from a comparably low spatial and temporal granularity, e.g., 64-bytes every few hundred cycles for cache attacks, to an arbitrary granularity, allowing an attacker to read every single bit. This is nothing any (cryptographic) algorithm can protect itself against. KAISER is a short-term software fix, but the problem we uncovered is much more significant.

Meltdown also heavily affects cloud providers, especially if the guests are not fully virtualized. For performance reasons, many hosting or cloud providers do not have an abstraction layer for virtual memory. In such environments, which typically use containers, such as Docker or OpenVZ, the kernel is shared among all guests. Thus, the isolation between guests can simply be circumvented with Meltdown, fully exposing the data of all other guests on the same host. For these providers, changing their infrastructure to full virtualization or using software workarounds such as KAISER would both increase the costs significantly.
Even if Meltdown is fixed, Spectre [19] will remain an issue. Spectre [19] and Meltdown need different defenses. Specifically mitigating only one of them will leave the security of the entire system at risk. We expect that Meltdown and Spectre open a new field of research to investigate in what extent performance optimizations change the microarchitectural state, how this state can be translated into an architectural state, and how such attacks can be prevented.
 
Why are people saying gaming would be unaffected? Surely a game requires many calls from the game code to the video drivers?
It's a security issue primarily.

There will be an impact on gaming, but it's likely to be smallish (<5%) and Intel only.
 
Meltdown vs Spectre CPU security flaws - What you need to know

Meltdown vs Spectre — What you need to know

It has been confirmed that the vulnerability is related to speculative execution — a mechanism CPUs rely on to keep their pipelines filled with instructions so they can be as efficient as possible.
 
Hmmm.

On Nov. 29, Brian Krzanich, the CEO of chip giant Intel (NASDAQ:INTC), reported several transactions in Intel stock in a Form 4 filing with the SEC.

Most of the transactions involved Krzanich exercising employee stock options (these options allowed Krzanich to purchase Intel shares at prices significantly below where they are currently trading) and then immediately selling those shares that he bought at a discount on the open market.

https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
 
[video=youtube;_qZksorJAuY]https://www.youtube.com/watch?v=_qZksorJAuY[/video]
 
I am seriously missing something here. For this malaware to be activated, someone using a browser has to run the code on the cpu *on the machine*. If you are using cloud based services, you are not using the cloud cpu to run that code. You are using your own cpu.
 
I am seriously missing something here. For this malaware to be activated, someone using a browser has to run the code on the cpu *on the machine*.
The exploit can be run by having you go to a web-site.

On that web-site it will have javascript that runs in the background and makes use of this malware.

It has been confirmed to work on Chrome for example, undoubtedly it'll work on any current browser.

The browser attack allows the code to access any data in your browser process.

So lets say you have internet banking open and this exploit runs they can hijack your internet banking session.

If you are using cloud based services, you are not using the cloud cpu to run that code. You are using your own cpu.

One of the functions that cloud companies provide is infrastructure to run your programs.
So you rent a computer from them by the hour.
You access the machine remotely.

There is an exploit that specifically targets computers running in virtualized mode.

Because cloud companies don't give you your own exclusive computer unless you pay lots of money for it, they carve up the machine into pieces.

Many people share the same machine but to each it seems like they have their own because it is virtualized.

However the exploit allows you to read the data of other virtual machines on that computer.

Amazon AWS have confirmed that they have patched their fleet for example.
I assume Azure and Google are doing the same.

As for your small timer companies, they'll probably take much longer... (if ever)
 
The exploit can be run by having you go to a web-site.

On that web-site it will have javascript that runs in the background and makes use of this malware.

It has been confirmed to work on Chrome for example, undoubtedly it'll work on any current browser.

The browser attack allows the code to access any data in your browser process.

So lets say you have internet banking open and this exploit runs they can hijack your internet banking session.



One of the functions that cloud companies provide is infrastructure to run your programs.
So you rent a computer from them by the hour.
You access the machine remotely.

There is an exploit that specifically targets computers running in virtualized mode.

Because cloud companies don't give you your own exclusive computer unless you pay lots of money for it, they carve up the machine into pieces.

Many people share the same machine but to each it seems like they have their own because it is virtualized.

However the exploit allows you to read the data of other virtual machines on that computer.

Amazon AWS have confirmed that they have patched their fleet for example.
I assume Azure and Google are doing the same.

As for your small timer companies, they'll probably take much longer... (if ever)
I thought that stuff disappeared when M$ stopped remote booting.
 
[video=youtube;_qZksorJAuY]https://www.youtube.com/watch?v=_qZksorJAuY[/video]

Installed update earlier today. No noticeable difference (at the moment) in my daily workloads, which includes running VMs etc.
 

From what you posted earlier it looks like these patches are not only for addressing the Intel issue but redesigning memory addressing in the OS's entirely?
So going forward even if Intel sort out their design issues re. speculative execution, the patches/new kernels will still be employed regardless?
Coming from a HPC perspective we can at least keep io/sys calls in mind going forward with our code.
 
Top
Sign up to the MyBroadband newsletter
X