linux-kernel - Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports

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: <a8e491304c28f74d9c8a61de4790e0584c40a19e.camel@HansenPartnership.com>
Date:   Sat, 05 Aug 2023 07:05:25 -0400
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     "Daniel P." Berrangé <berrange@...hat.com>,
        "Huang, Kai" <kai.huang@...el.com>
Cc:     "Williams, Dan J" <dan.j.williams@...el.com>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "sameo@...osinc.com" <sameo@...osinc.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jarkko@...nel.org" <jarkko@...nel.org>,
        "bp@...en8.de" <bp@...en8.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "dionnaglaze@...gle.com" <dionnaglaze@...gle.com>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "brijesh.singh@....com" <brijesh.singh@....com>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation
 reports

On Fri, 2023-08-04 at 17:19 +0100, Daniel P. Berrangé wrote:
> On Tue, Aug 01, 2023 at 11:45:12AM +0000, Huang, Kai wrote:
> > The IOCTL vs /sysfs isn't discussed.
> > 
> > For instance, after rough thinking, why is the IOCTL better than
> > below approach
> > using /sysfs?
> > 
> > echo <REPORTDATA> > /sys/kernel/coco/tdx/attest/reportdata
> > cat /sys/kernel/coco/tdx/attest/tdreport
> > 
> > Each "echo <REPORTDATA>" to '/sys/.../reportdata' triggers the
> > driver to call
> > TDCALL to get the TDREPORT, which is available at
> > '/sys/.../tdreport'.
> 
> What would you suggest as behaviour with multiple processes writing
> into 'reportdata' and trying to read from 'tdreport' in parallel ?
> Splitting input and output across separate files removes any
> transactional relationship between input and output. This approach
> feels like it could easily result in buggy behaviour from concurrent
> application usage, which would not be an issue with ioctl()

What's the use case where there are multiple outstanding reports?  The
only use case I've currently seen is single external relying party
requesting a report with a challenge.

> Also note, there needs to be scope for more than 1 input and 1 output
> data items. For SNP guests, the VMPL is a input, and if fetching a
> VMPL 0 report from under SVSM [1], an optional service GUID is
> needed. With SVSM, there are three distinct output data blobs -
> attestation report, services manifest and certificate data.

That's quite simple isn't it?  All the possible additional input
parameters appear as files.  If you don't echo anything into them, they
take the default values.  There's usually a single parameter that
causes the transaction to start (usually the nonce) and the transaction
takes the current values from all the files.

I'm not saying sysfs can substitute for all the transactionality of
ioctl, but in this case where everything is low volume and single
threaded it seems a reasonable choice.  For a more volume based
transactional approach, something more configfs like would work better,
so is there a use case for that?

James