linux-kernel - Re: l1tf: Kernel suggests I throw away third of my memory. I'd rather not

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1c2a1134-02ec-7cee-ac06-df9f51f6e5b9@suse.cz>
Date:   Thu, 18 Oct 2018 09:10:40 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Dave Hansen <dave.hansen@...el.com>, Pavel Machek <pavel@....cz>,
        Michal Hocko <mhocko@...nel.org>
Cc:     hpa@...or.com, torvalds@...ux-foundation.org, ak@...ux.intel.com,
        kernel list <linux-kernel@...r.kernel.org>, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de
Subject: Re: l1tf: Kernel suggests I throw away third of my memory. I'd rather
 not

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...