linux-kernel - Re: [PATCH v8 5/5] x86/tdx: Add Quote generation 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: <84d736f4d9321bc1245e30b43c6c2bc18965f718.camel@intel.com>
Date:   Fri, 22 Jul 2022 11:16:17 +1200
From:   Kai Huang <kai.huang@...el.com>
To:     Dave Hansen <dave.hansen@...el.com>,
        Sathyanarayanan Kuppuswamy 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Isaku Yamahata <isaku.yamahata@...il.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H . Peter Anvin" <hpa@...or.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Tony Luck <tony.luck@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Wander Lairson Costa <wander@...hat.com>,
        marcelo.cerri@...onical.com, tim.gardner@...onical.com,
        khalid.elmously@...onical.com, philip.cox@...onical.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 5/5] x86/tdx: Add Quote generation support

On Thu, 2022-07-21 at 12:23 -0700, Dave Hansen wrote:
> On 7/21/22 11:57, Sathyanarayanan Kuppuswamy wrote:
> > > How does the VMM know how much to read/write?  I have a theory: the spec
> > > says that R12 is:
> > > 
> > > 	"Shared 4KB GPA as input – the memory contains a
> > > 	TDREPORT_STRUCT."
> > > 
> > > That's *A* 4KB GPA.  The maximum is one 4KB page.  That's the only thing
> > > that makes sense because there's no length in the ABI anywhere.
> > > 
> > > What am I missing?
> > I think you are looking into the old spec. Please check the version
> > "FEBRUARY 2022"
> > 
> > Following are the ABI details:
> > 
> > R11 - TDG.VP.VMCALL< GetQuote > sub-function per Table 2-3
> > R12 - Shared GPA as input – the memory contains a TDREPORT_STRUCT. The
> >        same buffer is used as output – the memory contains a TD Quote.
> > R13 -  Size of shared GPA. The size must be 4KB-aligned.
> 
> Yeah, silly me.  I assumed the ABI was stable and wouldn't be, you know,
> adding and removing parameters.
> 
> I still don't know how this all works.  You just said:
> 
> > Current ABI allows attestation service and agent to decide the quote size. So
> > we can't make assumptions on what that size will be.
> 
> But, the guest *HAS* to make assumptions, right?  It's allocating the
> buffer and handing a pointer and size over to the host.  It's also guest
> *userspace*.  In fact, this implementation *ABSOLUTELY* makes
> assumptions about the buffer size.
> 
> If host userspace some day decides it needs 5MB of space, then all the
> guests will just stop working.  This implementation is limited by the
> max page allocator size.
> 
> This all just seems to work by chance.

The Intel's Quote format is pretty much defined in some spec.  I don't know
whether the spec is public or not, though.  But Quote by definition has Intel's
certificates embedded so the size is indeed variable -- even though in reality
it can be treated as fixed as Intel's certificates don't change often.

Intel's QGS (Quote Generation Service) once had an API to query Quote size but
it  got removed somehow, and instead, Intel used hard-coded (8K or 16K I forgot)
buffer, which is big enough for now.

Also, theoretically, 3rd party can add more staff (i.e. their certificates) when
they deploy their own attestation services, so the Quote can even be 3rd party
dependent.

So in short, yes, we Quote size is variable and it is determined by userspace. 
But in reality, 16K is big enough for foreseeable future.

When using the vsock, userspace just uses standard socket API to read data from
QGS.  It has all the flexibility, for instance, it can read the header first
(which is couple of bytes and fixed size) and decode the exact Quote size.  Then
it can allocate a large enough buffer and read once for all.  How vsock in
kernel uses whatever shared buffer size is implemented by vsock and transparent
to the userspace.

But with GetQuote TDVMCALL we don't have the luxury.  Userspace needs to tell a
big enough buffer to the kernel since the GetQuote must receive the entire Quote
at once.

That being said, ideally, what we need is a TDVMCALL based communication
channel, instead of bunches of TDVMCALLs with each being associated one specific
operation (i.e. GetQuote).  But obviously this isn't the direction we are
heading.

-- 
Thanks,
-Kai