News for hackers. Stuff that matters.
Re:CacheOut: Leaking Data on Intel CPUs via Cache Evictions by MrBuddyCasino on Tuesday January 28, 2020 @02:09AM (#22167119)
Thanks for the explanation, but I‘m not sure I got why this can happen:

> To prevent the confusing situation where the same physical address has more than one index in the cache

Re:CacheOut: Leaking Data on Intel CPUs via Cache Evictions by marcan_42 on Tuesday January 28, 2020 @02:28AM (#22167192)
You can have several virtual addresses mapped to the same physical address. However, if you use bits that are not 1:1 mapped between those two to index into your cache, then you might end up with one virtual address getting cached in one place in L1, and the other getting cached in another place in L1. That would be bad, because you'd have two potentially inconsistent caches of the same memory.
Re:CacheOut: Leaking Data on Intel CPUs via Cache Evictions by MrBuddyCasino on Tuesday January 28, 2020 @04:07AM (#22167706)
> You can have several virtual addresses mapped to the same physical address.

Ah yes, of course. Is this something that actually happens (e.g. because of processes sharing memory, OS hands out different virtual addresses pointing to the same physical memory) or theoretical in nature?

Re:CacheOut: Leaking Data on Intel CPUs via Cache Evictions by Tuna-Fish on Saturday February 01, 2020 @05:08AM (#22209738)
It does happen, and not just for two different processes.

For example, a common trick to implement an efficient circular list for objects of varying size is to map the same physical addresses twice in adjacent locations. Then you can just use a pointer to the start of each object and have no special handling for the case where an object straddles the end of the allocated area.