linux-kernel - Re: [PATCH v8 02/11] x86/tdx: Introduce INTEL_TDX

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: <YVxhy0FnMAhxe0+N@google.com>
Date:   Tue, 5 Oct 2021 14:31:39 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     Sathyanarayanan Kuppuswamy Natarajan 
        <sathyanarayanan.nkuppuswamy@...il.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, Paolo Bonzini <pbonzini@...hat.com>,
        David Hildenbrand <david@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Juergen Gross <jgross@...e.com>, Deep Shah <sdeep@...are.com>,
        VMware Inc <pv-drivers@...are.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, Peter H Anvin <hpa@...or.com>,
        Tony Luck <tony.luck@...el.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8 02/11] x86/tdx: Introduce INTEL_TDX_GUEST config option

On Tue, Oct 05, 2021, Dave Hansen wrote:
> On 10/5/21 6:29 AM, Sathyanarayanan Kuppuswamy Natarajan wrote:
> > On Mon, Oct 4, 2021 at 9:53 PM Randy Dunlap <rdunlap@...radead.org> wrote:
> >> On 10/4/21 7:51 PM, Kuppuswamy Sathyanarayanan wrote:
> >>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >>> index 2b2a9639d8ae..c42dd8a2d1f4 100644
> >>> --- a/arch/x86/Kconfig
> >>> +++ b/arch/x86/Kconfig
> >>> @@ -865,6 +865,20 @@ config ACRN_GUEST
> >>>         IOT with small footprint and real-time features. More details can be
> >>>         found inhttps://projectacrn.org/.
> >>>
> >>> +config INTEL_TDX_GUEST
> >>> +     bool "Intel Trusted Domain eXtensions Guest Support"
> >>> +     depends on X86_64 && CPU_SUP_INTEL && PARAVIRT
> >>> +     depends on SECURITY
> >>> +     select X86_X2APIC
> >> Apparently some Intel CPUs don't have the x2apic feature, since the
> >> Kconfig help text for X86_X2APIC says:
> >>
> >>           This enables x2apic support on CPUs that have this feature.
> >>
> >> so how is it safe to set/enable/select that kconfig symbol?

It's safe because the X86_X2APIC=y doesn't force x2APIC mode, it only enables
support for x2APIC mode.  If the CPU doesn't support x2APIC the kernel will use
legacy xAPIC.

That said, using select instead of depends is silly.

> >> Will the x2apic code just safely not work if the h/w feature is
> >> missing?
> > For the TDX guest, x2apic will be emulated. So it will exist in our
> > case.

That's incorrect, TDX partially virtualizes (as opposed to fully emulates) x2APIC
and thus requires the CPU to support x2APIC.

> > Even if x2apic or TDX guest is not supported by CPU, it will boot just fine.
>
> This doesn't really explain the "select X86_X2APIC", though.
> 
> You just said that TDX doesn't *require* X2APIC.

Well, TDX requires the guest to support x2APIC if the guest wants to do anything
useful.

10.9.1. Virtual APIC Mode
 * Guest TDs must use virtualized x2APIC mode. xAPIC mode (using memory mapped
   APIC access) is not allowed.
 * Guest TD attempts to RDMSR or WRMSR the IA32_APIC_BASE MSR cause a #VE to the
   guest TD. The guest TD cannot disable the APIC.