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

[Jan-Erik Soderholm]

Den 2018-01-06 kl. 23:34, skrev Tim Streater:
> In article <p2rh0g$876$1 at Iltempo.Update.UU.SE>, Johnny Billquist
> <bqt at softjar.se> wrote:
> 
>> On 2018-01-06 19:23, Tim Streater wrote:
>>> In article <p2qtjk$ul0$1 at Iltempo.Update.UU.SE>, Johnny Billquist
>>> <bqt at softjar.se> wrote:
>>>
>>>> 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.
>>>
>>> Never mind invalidating it. WTF is going on if a non-priv process has
>>> the right to do anything at all to the cache? Non-priv processes
>>> shouldn't even be aware that there *is* a cache, never mind having the
>>> right to execute instructions *about* the cache.
>>
>> Normally, that is true. But clever people can do a lot around this.
>> When I was doing my CS major, we had a course on advanced computer 
>> architectures, in where we learned how to write a very simple program 
>> that told us everything about cache size, associativeness, line size, TLB 
>> size, TLB associativeness, and so on...
>> All you need to do is understand how the computer is affected by these 
>> things, and then write programs that detect the effects.
>>
>> In short, you write small loops that exercise the cache in different 
>> ways, and time the whole thing. You don't even need any high precision 
>> timers for it. All user level, and all very simple.
> 
> Does that involve instructions that operate on the cache. Such as
> "clear cache"?
> 

You just read some unrelated (to the actual tests) data, so that the
test that you are running are 100% non-chached. If that is what your
tests are about.

And anyway, you can never "clear" any memory, being it the cache or any
other memory. Each byte will always have a value between x'00' and x'FF'.