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

[Jan-Erik Soderholm]

Den 2018-01-06 kl. 20:45, skrev johnwallace4 at yahoo.co.uk:
> On Saturday, 6 January 2018 16:30:46 UTC, Johnny Billquist  wrote:
>> On 2018-01-06 17:11, Alan Browne wrote:
>>> 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.
>>
>> Nothing like that either. You just speculatively read data that is in
>> theYOUR address space, but protected from user access. The speculative
>> execution fetches the data, even though you are not allowed to read it.
>> No CS, not even any privilege level change happened.
>>
>> You just make a speculative execution of an instruction that would fail
>> because you do not have the right to access the memory, but since it is
>> speculative, the trap never happens, as it later turns out that the
>> speculation was wrong. However, the data was still read, since the
>> speculative execution itself actually bypass the protection. The
>> protection trap will only hit you if the instruction is decided that it
>> actually would happen.
>> But unfortunately, the cache will still hold the read data that you were
>> not supposed to see.
>> And then they figured out a clever way of mining the contents of the cache.
>>
>> One could argue that the cache should be invalidated in such a scenario,
>> but that is not happening either.
>>
>>     Johnny
>>
>> -- 
>> Johnny Billquist                  || "I'm on a bus
>>                                     ||  on a psychedelic trip
>> email: bqt at softjar.se             ||  Reading murder books
>> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
> 
> One could argue, and smart people have argued, that
> side effects of speculative instructions should not
> become visible until such time as the instruction in
> question is confirmed as one which will be executed
> (nb in cases like this, an instruction which is
> initially executed is not always an instruction which
> completes e.g. it may be interrupted because of an
> exception or whatever, and therein lies another world
> of fun where great engineering care is always needed
> but is not always used).
> 
> A speculative fetch from main memory directly into a
> (shadowed) CPU register, a reference which bypasses
> cache because it's been told to (e.g. because the
> reference in question is to a region declared
> non-cacheable) can in general be discarded when the
> instruction is discarded because the speculation
> turned out to be wrong. And the affected shadowed
> register never gets to be visible. And on a good
> day there won't be any visible side effects.
> 

That is exactely what happens, the actuall *value* read from the
protected memory is never accesable or readable to the user code.

The clever thing is that you force a (fully valid) read from an
array that is completely within your own user memory, using the
protected value as an index. And that is run by the "prefetch",
"preexecute" unit in the processor.

Later on, you can use some clever timing tools to check what
member of your own array is cached (timing read access times).


> A speculative fetch from main memory into a register,
> one which does go into cache,...

The protected value might be in the cache, or it might not.
It doesn't matter, you do not need that value and you cannot
force a read directly from the cache anyway...