linux-kernel - Re: [RFC v1 05/26] x86/traps: Add #VE support for TDX guest

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <7d0b08c4-5ae7-f914-e217-767a9fae7b78@intel.com>
Date:   Fri, 12 Feb 2021 13:06:49 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Raj Ashok <ashok.raj@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Sean Christopherson <sean.j.christopherson@...el.com>
Subject: Re: [RFC v1 05/26] x86/traps: Add #VE support for TDX guest

On 2/12/21 12:54 PM, Sean Christopherson wrote:
> Ah, I see what you're thinking.
> 
> Treating an EPT #VE as fatal was also considered as an option.  IIUC it was
> thought that finding every nook and cranny that could access a page, without
> forcing the kernel to pre-accept huge swaths of memory, would be very difficult.
> It'd be wonderful if that's not the case.

We have to manually set up the page table entries for every physical
page of memory (except for the hard-coded early stuff below 8MB or
whatever).  We *KNOW*, 100% before physical memory is accessed.

There aren't nooks and crannies where memory is accessed.  There are a
few, very well-defined choke points which must be crossed before memory
is accessed.  Page table creation, bootmem and the core page allocator
come to mind.

If Linux doesn't have a really good handle on which physical pages are
accessed when, we've got bigger problems on our hands.  Remember, we
even have debugging mechanisms that unmap pages from the kernel when
they're in the allocator.  We know so well that nobody is accessing
those physical addresses that we even tell hypervisors they can toss the
page contents and remove the physical backing (guest free page hinting).