linux-kernel - Re: [RFC v1 00/26] Add TDX Guest Support

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: <CAPcyv4jx6cpdimDjyJtVkHLGmq_jcb0SWpz+Yx05iB0LM9CUyw@mail.gmail.com>
Date:   Mon, 12 Apr 2021 10:24:32 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        Raj Ashok <ashok.raj@...el.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v1 00/26] Add TDX Guest Support

On Sun, Apr 4, 2021 at 8:02 AM Dave Hansen <dave.hansen@...el.com> wrote:
>
> It occurred to me that I've been doing a lot of digging in the TDX spec
> lately.  I think we can all agree that the "Architecture Specification"
> is not the world's easiest, most disgestable reading.  It's hard to
> figure out what the Linux relation to the spec is.
>
> One bit of Documentation we need for TDX is a description of the memory
> states.  For instance, it would be nice to spell out the different
> classes of memory, how they are selected, who selects them, and who
> enforces the selection.  What faults are generated on each type and who
> can induce those?
>
> For instance:
>
> TD-Private memory is selected by the Shared/Private bit in Present=1
> guest PTEs.  When the hardware page walker sees that bit, it walk the
> secure EPT.  The secure EPT entries can only be written by the TDX
> module, although they are written at the request of the VMM.  The TDX
> module enforces rules like ensuring that the memory mapped by secure EPT
> is not mapped multiple times.  The VMM can remove entries.  From the
> guest perspective, all private memory accesses are either successful, or
> result in a #VE.  Private memory access does not cause VMExits.
>
> Would that be useful to folks?

That paragraph was useful for me as someone coming in cold to TDX
patch review. +1 for more of that style of commentary.