linux-kernel - Re: [PATCH] x86/tdx: Allow extended topology CPUID leafs to be emulated by hypercall

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: <CAAhR5DGUjeU=QoQdSXSLqaKiQ6U-Q8+sRQhnijHHtUtHfgh01Q@mail.gmail.com>
Date:   Fri, 8 Sep 2023 12:25:57 -0700
From:   Sagi Shahar <sagis@...gle.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Jun Nakajima <jun.nakajima@...el.com>,
        Isaku Yamahata <isaku.yamahata@...el.com>,
        Erdem Aktas <erdemaktas@...gle.com>,
        Vishal Annapurve <vannapurve@...gle.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Nikolay Borisov <nik.borisov@...e.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/tdx: Allow extended topology CPUID leafs to be
 emulated by hypercall

On Fri, Sep 8, 2023 at 11:00 AM Dave Hansen <dave.hansen@...el.com> wrote:
>
> On 9/8/23 10:56, Sagi Shahar wrote:
> > The current TDX module does not handle extended topology leaves
> > explicitly and will generate a #VE but the current #VE handler
> > implementation blindly returns 0 for those CPUID leaves.
> >
> > This currently causes TDX guests to see 0 values when querying the numa
> > topology leading to incorrect numa configurations.
> >
> > This patch fixes this behavior by emulating the extended topology leaves
> > using the CPUID hypercall.
>
> ... and thus acquires the data from the untrusted VMM.  Right?
>
> What are the security implications of consuming this untrusted data?

The topology information is mostly used for performance optimizations
on the guest side. I don't see any security implications if VMM passes
incorrect values.
Right now, the guest is already using the returned 0 values and gets
an incorrect numa topology leading to odd behavior in the guest. If we
allow guests to read these values from the untrusted VMM and VMM
spoofs the values, the worst that can happen is a different incorrect
numa topology instead of the incorrect one we already have today.