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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ