[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023062805-drove-privatize-ae2c@gregkh>
Date: Wed, 28 Jun 2023 08:46:08 +0200
From: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To: "Huang, Kai" <kai.huang@...el.com>
Cc: "Williams, Dan J" <dan.j.williams@...el.com>,
"dionnaglaze@...gle.com" <dionnaglaze@...gle.com>,
"corbet@....net" <corbet@....net>,
"Aktas, Erdem" <erdemaktas@...gle.com>,
"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
"shuah@...nel.org" <shuah@...nel.org>,
"Du, Fan" <fan.du@...el.com>, "Luck, Tony" <tony.luck@...el.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"brijesh.singh@....com" <brijesh.singh@....com>,
"joey.gouly@....com" <joey.gouly@....com>,
"qinkun@...che.org" <qinkun@...che.org>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"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>,
"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>,
"dhowells@...hat.com" <dhowells@...hat.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, 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 :)
thanks,
greg k-h
Powered by blists - more mailing lists