Hacker News Reader

Comment by swsieber | Hacker News Reader

From what I underst and this fixes variants two and three which are cross ring and cross process data extraction. I believe their hardware mitigation is to separate the caches between those (or something to that effect). So there will still be a minor penalty hit for running multiple identical process compared to before.

That's my interpretation though, I don't know enough to say that's the correct interpretation.

View on HN

Does the hardware on x86 even know which cache is owned by which process? It knows which is elevated (kernel Vs. User Vs. Hypervisor, etc) but process isolation on x86 is largely a kernel API construct rather than a hardware one.

Unless I'm mistaken.

The answer is yes, if the processor supports PCID: https://news.ycombinator.com/item?id=16094349

  Simplistically, it allows TLB-cached page table contents to be tagged with a 
  context identifier, and limits the lookups in the TLB to only match within 
  the currently allowed context. TLB cached entires with a different PCID will 
  be ignored.

I think you are confusing the TLB and processor data caches.

PCIDs exist for virtual addresses and are implemented in the TLB, not the processor caches. The processor caches are physically indexed, not virtually indexed.

So, does the processor cache have a mechanism to tell which "process" to which a given line belongs? Nope. Two processes (or a process and the kernel) that share memory can be in two PCIDs, but share the processor caches.

You are correct. My assumption was that the original question is not focused on the data cache itself, and so the DTLB does qualify for "knowing" what belongs to which context.

Reply on news.ycombinator.com