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]

Date:   Wed, 28 Jun 2023 09:45:34 +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>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "brijesh.singh@....com" <brijesh.singh@....com>,
        "Luck, Tony" <tony.luck@...el.com>,
        "joey.gouly@....com" <joey.gouly@....com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "dionnaglaze@...gle.com" <dionnaglaze@...gle.com>,
        "qinkun@...che.org" <qinkun@...che.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.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>,
        "Du, Fan" <fan.du@...el.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>,
        "Aktas, Erdem" <erdemaktas@...gle.com>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "Yu, Guorui" <guorui.yu@...ux.alibaba.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v3 3/3] selftests/tdx: Test GetQuote TDX attestation
 feature

On Wed, 2023-06-28 at 11:02 +0200, gregkh@...uxfoundation.org wrote:
> On Wed, Jun 28, 2023 at 08:56:30AM +0000, Huang, Kai wrote:
> > 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".
> 
> So you think that there should be a custom user/kernel api for every
> single different CPU vendor?  That's not how kernel development works,
> sorry.  Let's try to unify them to make both the kernel, and userspace,
> sane.
> 
> And Dan is right, if this is handling keys, then the key subsystem needs
> to be used here instead of custom ioctls.
> 

Sure.  I have no objection to this.