[Info-vax] Intel junk...Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign

[Jan-Erik Soderholm]

Den 2018-01-05 kl. 15:15, skrev DaveFroble:
> 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?
> 

As I understand, as in Linux, the kernel memeory is mapped into each user
process memory space (for performance reasons). The speculative fetch done
by the hardware can read kernel memory directly. And when the protection
schemas detects this, the data is already in the internal CPU cache.

The solution seems to be to separate kernel and user memoery into separate
virtual memory areas. So a re-mapp of the memory mapping is needed each
time the process needs to read kernel memory, and that adds a perf cost.

And yes, it looks like different "levels" in the hardware are bit
out of sync...