Jan-Erik Soderholm wrote:
Den 2018-01-04 kl. 23:04, skrev Tim Streater:
In article , DaveFroble
wrote:

chrisv wrote:
Designed By India H1B Engineers wrote:

Crucially, these updates to both Linux and Windows will incur a
performance hit on Intel products. The effects are still being
benchmarked, however we're looking at a ballpark figure of five to
30 per cent slow down, depending on the task and the processor model.

This is ugly. Think of the large computing centers, for example
Google's data centers. Suddenly, they will need significantly more
CPU time, and thus electricity (and thus carbon), to get the job done?


And once all the spanners are tossed into the works, which will slow
things down, what happens when new CPUs without the issues are
available? Will computers forever be artificially slowed down?

A whole bunch of someones has seriously dropped the ball on this.
Protected memory should be just that, protected, with no way to avoid
the protection.

But AIUI, the protection isn't applied when the CPU does speculative
instruction execution. It's unclear why, though.


Becuse the designers, for performance reasons, has mapped kernel memory
into the user process address space and relies on the OS to check
protection before any kernel memory (or code) is accessed.

The issue with the current issues is that the hardware (the CPU) does
these accesses in hardware "under the hood" without control by the OS.

If you map your kernel memory in another way that uses the hardware
protection facilities, you are (as I understand) safe, at the cost
of worse performance to switch between user and kernel mode.



As I wrote, someone dropped the ball on this one.

Speculative execution is part of the HW, not software. It appears the HW
doesn't follow it's own rules. Or, perhaps I don't actually understand the problem?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail:
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486