From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA902523E for ; Sat, 5 Aug 2023 11:05:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1691233529; bh=Kp0V8XoBe7ftnnqF+Zb6Xx7gGt4oeSLO48BmsQvQNRs=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=dattdD7Q5Ya4ttLlIDRS/BH6AZTqW2rycXm2dneWDDiaOu5g3QRxb4S7iaAvJwjuR kNZ7BGvX1b+bsz1sit2Bp/THSHZPNVb0g+/j3tW31IHbCoIwYk7V0zdUEzh5GcI+tV PzbvV7HFjW1+ANgwQWrftApsoIDUPPhrFupl9Rf0= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 6BFD11286B03; Sat, 5 Aug 2023 07:05:29 -0400 (EDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavis, port 10024) with ESMTP id HtRUkobKztqP; Sat, 5 Aug 2023 07:05:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1691233529; bh=Kp0V8XoBe7ftnnqF+Zb6Xx7gGt4oeSLO48BmsQvQNRs=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=dattdD7Q5Ya4ttLlIDRS/BH6AZTqW2rycXm2dneWDDiaOu5g3QRxb4S7iaAvJwjuR kNZ7BGvX1b+bsz1sit2Bp/THSHZPNVb0g+/j3tW31IHbCoIwYk7V0zdUEzh5GcI+tV PzbvV7HFjW1+ANgwQWrftApsoIDUPPhrFupl9Rf0= Received: from [IPv6:2601:5c4:4302:c21::a774] (unknown [IPv6:2601:5c4:4302:c21::a774]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id D1D221286B02; Sat, 5 Aug 2023 07:05:27 -0400 (EDT) Message-ID: Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports From: James Bottomley To: "Daniel P." =?ISO-8859-1?Q?Berrang=E9?= , "Huang, Kai" Cc: "Williams, Dan J" , "dhowells@redhat.com" , "sameo@rivosinc.com" , "linux-kernel@vger.kernel.org" , "jarkko@kernel.org" , "bp@alien8.de" , "gregkh@linuxfoundation.org" , "peterz@infradead.org" , "akpm@linux-foundation.org" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "thomas.lendacky@amd.com" , "dionnaglaze@google.com" , "keyrings@vger.kernel.org" , "brijesh.singh@amd.com" , "linux-coco@lists.linux.dev" , "x86@kernel.org" Date: Sat, 05 Aug 2023 07:05:25 -0400 In-Reply-To: References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com> <64c5ed6eb4ca1_a88b2942a@dwillia2-xfh.jf.intel.com.notmuch> <6dec442c64faf2fecd21bcc77e4a6350e88948b9.camel@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 > /sys/kernel/coco/tdx/attest/reportdata > > cat /sys/kernel/coco/tdx/attest/tdreport > > > > Each "echo " 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