Correction of incipient security flaw in Intel CPUs

[cobito]

Something big is moving behind the scenes but no one is giving explanations for the moment. It is a security flaw whose details are being kept secret until the relevant patches for Linux and Windows are released.

Read more...

[Yorus]

I hope they clarify this more and see in which tasks the performance decrease will be noticed.

On the positive side, it is good to say that at least Intel has moved, because in terms of security, a bug that has not come to light or that could even be discovered by some group, entity or organization without notifying the manufacturer is worse than one that becomes public. It is similar to the typical case of a user who worries because their antivirus has triggered an alert and they have to be told that the dangerous thing is that it does not trigger and the user does not find out.

[Namiga]

Ya... But if a manufacturer's error takes away 30%... They should have it checked and replaced. But if it loses performance... We want it returned, as processors are not cheap.

[Yorus]

The issue is whether it's a matter of VT-x instructions as Cobito mentioned outside the forum, or as suspected in one of the links he posted, will the performance drop only affect the virtualization section (which is already very serious) or any general task?

[cobito]

That's a good observation, @Yorus. If it's a problem with the hypervisor's memory mapping and they've also said it doesn't affect AMD, the patch probably won't affect the common mortal (who doesn't use virtual machines).

Now, Intel is going to have a big problem when it has to respond to giants like Amazon and company that rely on their micros to offer virtual machines in the cloud.

[cobito]

Michael Larabel published on his Phoronix some tests with some interesting conclusions. The patch does affect performance in any task (even outside of virtualization). The impact depends on the interaction that the process has with the kernel since the patch operates precisely to prevent processes from having access to the kernel map ranges.

In file movement for example, the difference can be brutal depending on the model:

Video encoding is not affected although database management systems (Redis for example) or compilation do have a small penalty.

Gamers apparently have nothing to worry about (from a Core i7 8700K with Radeon RX Vega 64):

So the user-level action that seems to penalize performance the most are input/output operations from a storage device. Probably in SSDs the issue is especially bloody.

[Yorus]

According to comments, the patch is applied by default at least in Linux, regardless of whether we have an Intel or an AMD, so AMD users may also suffer that loss of performance as collateral damage.

[cobito]

ARM64 has also fallen so the issue extends to smartphones, tablets and gadgets in the field. Or seen from another perspective: from today there are millions of unsupported Android devices with a presumably serious security flaw.

[cobito]

Intel has published a list of affected models.

On Tom´s Hardware they have published an explanation of the vulnerabilities (Meltdown and Spectre). Meltdown is in principle a vulnerability that does not necessarily affect home users. Its danger lies in the possibility that a user of one virtual machine has to access the data of the memory of another virtual machine. This, in server farms that offer virtualized services, means that anyone could access data such as passwords resident in the memory of any virtual machine running on that same physical machine.

Spectre is a different problem that does affect AMD processors. For this security flaw there is no software solution and it will remain there until manufacturers sell CPUs with the bug fixed. But it is very difficult to exploit because the way to carry it out varies greatly from model to model.

From the point of view of nomenclature, do you think that the end of the Core era (i3, i5, i7...) has arrived?