On 10/18/18 12:21 AM, Dave Hansen wrote: > On 10/17/2018 04:32 AM, Pavel Machek wrote: >>> Well, that depends. Do you care about PROT_NONE attacks as well? If not >>> then no-swap would help you. But even then no-swap is rather theoretical >>> attack on a physical host unless you allow an arbitrary swapout to a >>> malicious user (e.g. allow a user controlled memcg hard limit that would >>> cause excessive local swapouts). >> PROT_NONE attack.. aha, so kernel stores not only information about >> swapped-out pages but also about file-backed pages that are currently >> not present? Hmm. That makes it more complex :-(. > > There are also migration PTE entries that are "swap-like". They can > exist even if you swapoff -a. > > Can we do better? Sure. I think we'd all be happy to review patches > that improve the situation if folks have simple ideas for improvement.
I think if would be rather unfortunate changing this fundamentally due to a HW bug that should hopefully eventually go away with new CPUs, and with MAX_PA/2 being limited only on very old CPUs. I don't think using page table entries like this is a hack. The pte must IMHO always carry some information that identifies is as swap entry or prot_none or whatever. If we had to look up the swap offset (or pfn associated with PROT_NONE pte elsewhere), there would be additional overhead both for storing this mapping and for looking it up. PTEs seems just like a natural place for this IMHO, and it's defined that the bits can be used by the kernel however it likes for !present PTEs. Why rewrite it all just because some CPUs implementation is not as defined...