Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 14 Aug 2023 09:21:05 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>,
        Dan Williams <dan.j.williams@intel.com>,
        <linux-coco@lists.linux.dev>
CC:     Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        Dionna Amalie Glaze <dionnaglaze@google.com>,
        James Bottomley <James.Bottomley@hansenpartnership.com>,
        Peter Gonda <pgonda@google.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Samuel Ortiz <sameo@rivosinc.com>, <peterz@infradead.org>,
        <x86@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/5] tsm: Introduce a shared ABI for attestation
 reports
Message-ID: <64da54713e2fb_2138e294d@dwillia2-xfh.jf.intel.com.notmuch>
References: <169199898909.1782217.10899362240465838600.stgit@dwillia2-xfh.jf.intel.com>
 <169199900110.1782217.12112722316618515086.stgit@dwillia2-xfh.jf.intel.com>
 <e1a7a56d-b77c-4728-a8c7-be8db640c909@linux.microsoft.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <e1a7a56d-b77c-4728-a8c7-be8db640c909@linux.microsoft.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?234qsNMTH9DcoUAawtAppl3c1CnUpK8CvW0gV7U4KuVO4uz/PiUMsG2Amr9h?=
 =?us-ascii?Q?V1olHlyeS3cTSYoLYRP6kA9YiA/YP4nYILCELUPi13BO8Kl/M1T1xSf0AHbd?=
 =?us-ascii?Q?ndnaMO9VkzROZz6hv9O/Ye/QOe7fIGlniAqMp05JUOtEPiLdaW5eCMUFKM5W?=
 =?us-ascii?Q?hbs8jO7yEHVvWcpspjPmTEhbPItHW+zZcLumk1Pg7nLstdwHFo3kr4SeuAwr?=
 =?us-ascii?Q?FXgpXqQOSk7zsnqFewfzDcS8bygxVDcpacdMwRFENKZzfV1REZ6Rre+aWgN7?=
 =?us-ascii?Q?PlP9Fur4vQ1e8EhiJ6nceSbAwBlbOPVJ4dMZCpg0nks+YHncbqWuc1L485T5?=
 =?us-ascii?Q?vnH+k4cEeCd8GZF+gPygHEmFz8QyUpf3L08pVUOoSA/KXymLeH4BKA5TzlV1?=
 =?us-ascii?Q?L8i3qdfiCO8Yyd3mAiNttrUA7fmzlMiHSUfeSCusVRYWY6F0ffapWGW1tC7n?=
 =?us-ascii?Q?+FkOPOVs0Wvs5BKpS0HyXydnLHN0EJ979O5tn+P+zgNW1PPsyQ0jCfWVLQ+d?=
 =?us-ascii?Q?vFJ/ysp/gYR33ZVH4dx5YTJGk8eiqHjd9owuss3iwPcSY43INjbWQ/tpZ51F?=
 =?us-ascii?Q?wdaDW2pCynDIT8QB/ZgiRs6xboTf+LfguiYszqfP+p0WTK3ReY9+gNHUH0C4?=
 =?us-ascii?Q?BxEsNO5WJiF7hbseAeV5sIjjG4Neah6SUSAzzTjtyIusUyxaRSqG6ezIOuHq?=
 =?us-ascii?Q?0MbnWZtVV9iHiqeP+dgKaqq7cc30ZYeTq6xxjnJpHfG0FBr4jWAD9wj7SqOy?=
 =?us-ascii?Q?NemG1R2b6z5mJBvHyARtdqxz01OiQKDhYiJCD5Wu6sOVa9ubs4Zus2mofliU?=
 =?us-ascii?Q?K8Bm8ZxS678TTTYS/E0Y2R93OFwYEqIGHGDfrDD08OfOwMFV1ZZqKSTlptZr?=
 =?us-ascii?Q?AR23V7mMRYfEKY3V3V/R1H7Vita16st103glVdnTBs8Pw3tKNBzpD5WT8Zf1?=
 =?us-ascii?Q?wyC00p/DJ5a3454eBQOGrjSia4hq7BVIpdVsYg0pUbhAOuHAS4ZjlGkd91w1?=
 =?us-ascii?Q?3Gbd0cYdpMBpFpRWgajzqyAjFoph2tgDl0EtNqazBxhdQHo/gYTyrSnzlZRA?=
 =?us-ascii?Q?4UDRH9hgecvyLjuavzizXaknJPu+Vinz5FZY2/WOdTE9atUrLYVIfj8+B/6B?=
 =?us-ascii?Q?F3eT2CgUAfsM6HW/1XAtW4Jyap6WIXFknTdwUuU1bkxS+VMF0B2x0YecSDsT?=
 =?us-ascii?Q?ANnFKe9VQoQP/i+trxk9jSG/eLYos+KIxa9NcPoyv2gzvmNo/9Au2shjpFhv?=
 =?us-ascii?Q?AMvQV9V0msOIvYKZGyk37UhpgP844SCK4i2/pDezj8sOpvMy4h0XgmMKxtDn?=
 =?us-ascii?Q?gwabUF4RYCprpECH3WQVxukdAfDvXHSADvbLzdAp5Tk/Ir0qW2xuxEqeuP4D?=
 =?us-ascii?Q?+6pgfgY6yNBtcuzwYZMew1wHZMeXWFUZwuP7z2U1QiIQwTA8uJcAbRC72PAy?=
 =?us-ascii?Q?EV6+67/xj86gh/sUoJYj/7h4jjjcVZYSqPq/objJqSb9kkQNl/ucJYLuJu+9?=
 =?us-ascii?Q?D6DRxGqo0e92b2Q9e/7xl/b2Zkks1JRfK249UkU5Y+38ksOvb7GqnjG8SXRC?=
 =?us-ascii?Q?i7HNqBfDIlWEs69oTsc8P7C33/tuHk20kbrQtl2EhnZ3vZtdf2jgRL1dUUXp?=
 =?us-ascii?Q?ow=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 104430a1-4568-4c93-ab8d-08db9ce2774b
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Aug 2023 16:21:08.3286
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tQpTJC5/Kbd0OFhFPeO+epz4GBH7hneAy9vWIKlCvnH6at/liR4kkzygpswnDQfSHW7nrUfBw64WSmJ3vd1gSNKyV5aTU6R4xPpBklhCNS4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB6621
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
        RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Jeremi Piotrowski wrote:
> On 8/14/2023 9:43 AM, Dan Williams wrote:
> > One of the common operations of a TSM (Trusted Security Module) is to
> > provide a way for a TVM (confidential computing guest execution
> > environment) to take a measurement of its launch state, sign it and
> > submit it to a verifying party. Upon successful attestation that
> > verifies the integrity of the TVM additional secrets may be deployed.
> > The concept is common across TSMs, but the implementations are
> > unfortunately vendor specific. While the industry grapples with a common
> > definition of this attestation format [1], Linux need not make this
> > problem worse by defining a new ABI per TSM that wants to perform a
> > similar operation. The current momentum has been to invent new ioctl-ABI
> > per TSM per function which at best is an abdication of the kernel's
> > responsibility to make common infrastructure concepts share common ABI.
> > 
> > The proposal, targeted to conceptually work with TDX, SEV, COVE if not
> > more, is to define a sysfs interface to retrieve the TSM-specific blob.
> > 
> >     echo $hex_encoded_userdata_plus_nonce > /sys/class/tsm/tsm0/inhex
> >     hexdump /sys/class/tsm/tsm0/outblob
> > 
> > This approach later allows for the standardization of the attestation
> > blob format without needing to change the Linux ABI. Until then, the
> > format of 'outblob' is determined by the parent device for 'tsm0'.
> > 
> > The expectation is that this is a boot time exchange that need not be
> > regenerated, making it amenable to a sysfs interface. In case userspace
> > does try to generate multiple attestation reports it includes conflict
> > detection so userspace can be sure no other thread changed the
> > parameters from its last configuration step to the blob retrieval.
> > 
> > TSM specific options are encoded as 'extra' attributes on the TSM device
> > with the expectation that vendors reuse the same options for similar
> > concepts. The current options are defined by SEV-SNP's need for a
> > 'privilege level' concept (VMPL), and the option to retrieve a
> > certificate chain in addition to the attestation report ("extended"
> > format).
> > 
> > Link: http://lore.kernel.org/r/64961c3baf8ce_142af829436@dwillia2-xfh.jf.intel.com.notmuch [1]
> > Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> > Cc: Dionna Amalie Glaze <dionnaglaze@google.com>
> > Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
> > Cc: Peter Gonda <pgonda@google.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Samuel Ortiz <sameo@rivosinc.com>
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > ---
[..]
> > +static ssize_t outblob_read(struct file *f, struct kobject *kobj,
> > +			    struct bin_attribute *bin_attr, char *buf,
> > +			    loff_t offset, size_t count)
> > +{
> > +	guard(rwsem_read)(&tsm_rwsem);
> 
> This is unfortunate but it would need to be a rwsem_write otherwise two
> processes can race to reach the kvfree and both call report_new at the
> same time (unlikely as it may be).

Ugh, yup, good eye, will fix.