linux-kernel - RE: [PATCH v11 00/20] TDX host kernel 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: <6482423c7c52a_142af8294a6@dwillia2-xfh.jf.intel.com.notmuch>
Date:   Thu, 8 Jun 2023 14:03:56 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Kai Huang <kai.huang@...el.com>, <linux-kernel@...r.kernel.org>,
        <kvm@...r.kernel.org>
CC:     <linux-mm@...ck.org>, <dave.hansen@...el.com>,
        <kirill.shutemov@...ux.intel.com>, <tony.luck@...el.com>,
        <peterz@...radead.org>, <tglx@...utronix.de>, <seanjc@...gle.com>,
        <pbonzini@...hat.com>, <david@...hat.com>,
        <dan.j.williams@...el.com>, <rafael.j.wysocki@...el.com>,
        <ying.huang@...el.com>, <reinette.chatre@...el.com>,
        <len.brown@...el.com>, <ak@...ux.intel.com>,
        <isaku.yamahata@...el.com>, <chao.gao@...el.com>,
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        <bagasdotme@...il.com>, <sagis@...gle.com>, <imammedo@...hat.com>,
        <kai.huang@...el.com>
Subject: RE: [PATCH v11 00/20] TDX host kernel support

Kai Huang wrote:
> Intel Trusted Domain Extensions (TDX) protects guest VMs from malicious
> host and certain physical attacks.  TDX specs are available in [1].
> 
> This series is the initial support to enable TDX with minimal code to
> allow KVM to create and run TDX guests.  KVM support for TDX is being
> developed separately[2].  A new "userspace inaccessible memfd" approach
> to support TDX private memory is also being developed[3].  The KVM will
> only support the new "userspace inaccessible memfd" as TDX guest memory.

This memfd approach is incompatible with one of the primary ways that
new memory topologies like high-bandwidth-memory and CXL are accessed,
via a device-special-file mapping. There is already precedent for mmap()
to only be used for communicating address value and not CPU accessible
memory. See "Userspace P2PDMA with O_DIRECT NVMe devices" [1].

So before this memfd requirement becomes too baked in to the design I
want to understand if "userspace inaccessible" is the only requirement
so I can look to add that to the device-special-file interface for
"device" / "Soft Reserved" memory like HBM and CXL.

[1]: https://lore.kernel.org/all/20221021174116.7200-1-logang@deltatee.com/