On Wed 17-10-18 12:56:10, Pavel Machek wrote: > Hi! > > 6a012288 suggests I throw away 1GB on RAM. On 3GB system.. that is not > going to be pleasant. > > l1tf.html says: > > # The Linux kernel contains a mitigation for this attack vector, PTE > # inversion, which is permanently enabled and has no performance > # impact. > > I don't believe it has "no" performance impact, but I guess it is lost > in the noise.
Please prove otherwise. I would be more than surprised if inverting pfn part of the pte is noticeable. But I can be wrong of course. > # The kernel ensures that the address bits of PTEs, which are > # not marked present, never point to cacheable physical memory space. > > # A system with an up to date kernel is protected against attacks from > # malicious user space applications. > > These are not true. > > cat /sys/devices/system/cpu/vulnerabilities/l1tf > Vulnerable > uname -a > Linux amd 4.19.0-rc8-next-20181017autobisect1539371050 #189 SMP Wed > Oct 17 12:04:23 CEST 2018 i686 GNU/Linux This is a result of you having memory above MAX_PFN/2 right? > Now question is... can we do better? Kernel stores information about > swapped-out pages there, right? That sounds like a cool hack, but > maybe it is time to get rid of that hack? Patches are welcome. > As a workaround, can I simply do swapoff -a to be safe for now? 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). -- Michal Hocko SUSE Labs