linux-kernel - Re: [RFC v2-fix 1/1] x86/tdx: Handle in-kernel MMIO

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: <94dc5a5a-8c51-8624-5810-e6278783789c@intel.com>
Date:   Tue, 18 May 2021 09:04:50 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Andi Kleen <ak@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>
Cc:     Tony Luck <tony.luck@...el.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>,
        Sean Christopherson <seanjc@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC v2-fix 1/1] x86/tdx: Handle in-kernel MMIO

On 5/18/21 8:56 AM, Andi Kleen wrote:
> On 5/18/2021 8:00 AM, Dave Hansen wrote:
>> On 5/17/21 5:48 PM, Kuppuswamy Sathyanarayanan wrote:
>>> From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
>>>
>>> In traditional VMs, MMIO tends to be implemented by giving a
>>> guest access to a mapping which will cause a VMEXIT on access.
>>> That's not possible in TDX guest.
>> Why is it not possible?
> 
> For once the TDX module doesn't support uncached mappings (IgnorePAT is
> always 1)

Actually, I was thinking more along the lines of why the architecture
doesn't have VMEXITs:  VMEXITs expose guest state to the host and VMMs
use that state to emulate MMIO.  TDX guests don't trust the host and
can't have that arbitrary state exposed to the host.  So, they sanitize
the state in the #VE handler and make a *controlled* transition into the
host with a TDCALL rather than an uncontrolled VMEXIT.

>>> For now we only handle a subset of instructions that the kernel
>>> uses for MMIO operations. User-space access triggers SIGBUS.
>> How do you know which instructions the kernel uses?
> 
> They're all in MMIO macros.

I've heard exactly the opposite from the TDX team in the past.  What I
remember was a claim that one can not just leverage the MMIO macros as a
single point to avoid MMIO.  I remember being told that not all code in
the kernel that does MMIO uses these macros.  APIC MMIO's were called
out as a place that does not use the MMIO macros.

I'm confused now.

>>   How do you know that the compiler won't change them?
> 
> The macros try hard to prevent that because it would likely break real
> MMIO too.
> 
> Besides it works for others, like AMD-SEV today and of course all the
> hypervisors that do the same.

That would be some excellent information for the changelog.