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

[Jan-Erik Soderholm]

Den 2018-01-06 kl. 16:27, skrev Alan Browne:
> On 2018-01-05 16:00, DaveFroble wrote:
>> Alan Browne wrote:
>>> On 2018-01-05 09:15, DaveFroble wrote:
>>>> Jan-Erik Soderholm wrote:
>>>
>>>>> 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?
>>>
>>> At least as well as I do.  These are very complex mechanisms and 
>>> complexity is usually where you're most likely to get problems.
>>>
>>> In this case the h/w implementation didn't reflect the design goal.
>>>
>>> This means intel had very poor design review and abysmal testing of 
>>> security features.
>>>
>>
>> There seems a whole bunch of us "speculating" about things we probably 
>> don't know enough about.
> 
> I am very certain that they either did not design the testing correctly or 
> didn't test per the test plan correctly.  Or a bad scenario: they saw it 
> and carpeted it.
> 
>>
>> :-)
>>
>> It seems to me that before memory is fetched into cache, the CPU should 
>> be determining whether it should indeed be fetching that memory.  Yeah, 
> 
> The CPU memory controller is (usually) the arbiter of whether a fetch is 
> "legal" in the privilege scheme - so if something is allowed to be fetched, 
> then it is fetched.  So (hierarchically) the fetch goes to the decoding 
> pipeline(s) -and- is simultaneously copied to the cache.  At that point the 
> MC has "allowed" the fetch.  Writes to memory are also written to cache.  
> The issue seems to be that post fetch from Kernel assigned memory, the 
> cache makes some privileged data available to lower priority tasks after 
> the context switch.  That is the gist.
> 

As I understand, the CPU fetched prived data "under the hood" even before
the processor has decided that it was prived data. When the user process
get an "slap on the hand", the tracks was already in the cache.

There was never any "context switch" involved at all, it was way below
such constructs. Everything was done from user level "under the radar"
from the point of view of the any OS (or the protection facilities in
the CPU itself, it also seems).

And it never made any priviledge data avalable at all. It used the prived
data (byte) that was pre-fetched as an index into an array in user memory
and could later identify what element of the user data that was touched.

Clever...






>> sounds simple, but I'm betting it isn't.
> 
> I recall when pipelining came to simple microprocessors and we were in the 
> lab swapping processors and measuring the performance gains and salivating 
> over not much... or IIRC a competitor to the 8088 came out with some cycles 
> saved on some instructions and we were doing the same thing.  Then 
> pre-fetching came - then predictive decoding and so on ...
> 
> What they do these days in processors in mind-boggling layers of complexity 
> before you even get close to privilege management.
> 
> To me though, multicore processing is the best achievement.  Certainly 
> makes OS's and apps very smooth in operation.
>