[Info-vax] Intel junk...Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign
DaveFroble
davef at tsoft-inc.com
Fri Jan 5 09:15:15 EST 2018
Jan-Erik Soderholm wrote:
> Den 2018-01-04 kl. 23:04, skrev Tim Streater:
>> In article <p2m3kt$vnk$1 at dont-email.me>, DaveFroble
>> <davef at tsoft-inc.com> 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: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
More information about the Info-vax
mailing list