linux-kernel - Re: [PATCH v3 3/3] selftests/tdx: Test GetQuote TDX attestation feature

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: <e30fb40d736ccc60672316c5d20aaf1ab7c94dcf.camel@intel.com>
Date:   Wed, 28 Jun 2023 08:56:30 +0000
From:   "Huang, Kai" <kai.huang@...el.com>
To:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC:     "corbet@....net" <corbet@....net>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "Yu, Guorui" <guorui.yu@...ux.alibaba.com>,
        "Luck, Tony" <tony.luck@...el.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "joey.gouly@....com" <joey.gouly@....com>,
        "dionnaglaze@...gle.com" <dionnaglaze@...gle.com>,
        "qinkun@...che.org" <qinkun@...che.org>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Du, Fan" <fan.du@...el.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "wander@...hat.com" <wander@...hat.com>,
        "atishp@...osinc.com" <atishp@...osinc.com>,
        "Aktas, Erdem" <erdemaktas@...gle.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "chongc@...gle.com" <chongc@...gle.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "brijesh.singh@....com" <brijesh.singh@....com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "dhowells@...hat.com" <dhowells@...hat.com>
Subject: Re: [PATCH v3 3/3] selftests/tdx: Test GetQuote TDX attestation
 feature

On Wed, 2023-06-28 at 08:46 +0200, gregkh@...uxfoundation.org wrote:
> On Wed, Jun 28, 2023 at 02:16:45AM +0000, Huang, Kai wrote:
> > > You really shouldn't be putting attestation validation logic in the
> > > kernel.
> > 
> > Agreed.  The data blob for remote verification should be just some data blob to
> > the kernel.  I think the kernel shouldn't even try to understand the data blob
> > is for which architecture.  From the kernel's perspective, it should be just
> > some data blob that the kernel gets from hardware/firmware or whatever embedded
> > in the root-of-trust in the hardware after taking some input from usrspace for
> > the unique identity of the blob that can be used to, e.g., mitigate replay-
> > attack, etc.
> 
> Great, then use the common "data blob" api that we have in the kernel
> for a very long time now, the "firwmare download" api, or the sysfs
> binary file api.  Both of them just use the kernel as a pass-through and
> do not touch the data at all.  No need for crazy custom ioctls and all
> that mess :)
> 

I guess I was talking about from "kernel shouldn't try to parse attestation data
blob" perspective.  Looking at AMD's attestation flow (I have no deep
understanding of AMD's attestation flow), the assumption of "one remote
verifiable data blob" isn't even true -- AMD can return "attestation report"
(remote verifiable) and the "certificate" to verify it separately:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snp-attestation.html

On the other hand, AFAICT Intel SGX-based attestation doesn't have a mechanism
"for the kernel" to return certificate(s), but choose to embed the
certificate(s) to the Quote itself.  I believe we can add such mechanism (e.g.,
another TDVMCALL) for the kernel to get certificate(s) separately, but AFAICT it
doesn't exist yet.

Btw, getting "remote verifiable blob" is only one step of the attestation flow.
For instance, before the blob can be generated, there must be a step to
establish the attestation key between the machine and the attestation service. 
And the flow to do this could be very different between vendors too.

That being said, while I believe all those differences can be unified in some
way, I think the question is whether it is worth to put such effort to try to
unify attestation flow for all vendors.  As Erdem Aktas mentioned earlier, "the
number of CPU vendors for confidential computing seems manageable".