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

[Alan Browne]

On 2018-01-06 11:06, Jan-Erik Soderholm wrote:
> 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).

I didn't mean OS level CS but privilege level switching.  Sorry for the 
ambiguity.

> 
> 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...

Interesting.


-- 
“When it is all said and done, there are approximately 94 million
  full-time workers in private industry paying taxes to support 102
  million non-workers and 21 million government workers.
  In what world does this represent a strong job market?”
.Jim Quinn