From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web12.4920.1634886109240498210 for ; Fri, 22 Oct 2021 00:01:49 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JW7qn7dT; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634886108; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/YS8K4YMBNmx2xdIzemz0qwXwcz6imDxNCuWMdUEU7s=; b=JW7qn7dTi/eWHPsNrFfuDLGpGZbKQw4pmukLVf2hCxhziYp9K1dKG0Qf1WuzqTbrZbV4Qr RBxKka9jiwbXW5plJpgAH69+lkDfauRnDVqMOuP7k7AWdDlWQslzNHpNK6/h+OigKnxabj iVw9rMG4WYo7jOs2GryNt1QiGMUo1L8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-118-m3onJXGAPwOZTXyUZaih7Q-1; Fri, 22 Oct 2021 03:01:45 -0400 X-MC-Unique: m3onJXGAPwOZTXyUZaih7Q-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CC4DE802B7A; Fri, 22 Oct 2021 07:01:43 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 906D75C1A3; Fri, 22 Oct 2021 07:01:39 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id DD66E180060F; Fri, 22 Oct 2021 09:01:37 +0200 (CEST) Date: Fri, 22 Oct 2021 09:01:37 +0200 From: "Gerd Hoffmann" To: Stefan Berger Cc: devel@edk2.groups.io, James Bottomley , Min Xu , Jordan Justen , Erdem Aktas , Ard Biesheuvel , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Jiewen Yao , Tom Lendacky , Brijesh Singh Subject: Re: [PATCH 0/4] OvmfPkg: rework TPM configuration. Message-ID: <20211022070137.jn5nngecb6hbptvd@sirius.home.kraxel.org> References: <20211021122003.2008499-1-kraxel@redhat.com> <7052ea1f-8bed-f556-8882-685718c91195@linux.ibm.com> MIME-Version: 1.0 In-Reply-To: <7052ea1f-8bed-f556-8882-685718c91195@linux.ibm.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Oct 21, 2021 at 12:13:51PM -0400, Stefan Berger wrote: > A few more comments to this series: > > - Is there a use case where TPM2_ENABLE_CONFIG is disabled, meaning where > there should not be a TPM 2 menu entry? It's worth considering dropping this > option because a user does need to have control over certain aspects of the > TPM 2 configuration. I happily drop the option if it doesn't make sense. I've already wondered why it is there but assumed there is some valid reason for it and left it as-is. > - Should it be possible to enable TPM 1.2 independent of TPM 2? For me it's > fine as-is since TPM 2 is mostly used these days... Exactly. With the world moving to TPM 2 building OVMF with TPM 1.2 only looks pointless to me. > - I would drop patch 4 if it means that an active SHA1 bank doesn't get PCR > extensions (haven't tested yet). swtpm_setup currently sets up a swtpm with > active SHA1 and SHA256 PCR banks ( https://github.com/stefanberger/swtpm/blob/master/src/swtpm_setup/swtpm_setup.c#L65 > ). We can change this for swtpm v0.7.0 to only activate the SHA256 bank, if > that's what is needed here. However, this doesn't prevent a user to activate > the SHA1 PCR bank either via PPI 'request' file or UEFI TPM menu and when it > is active it must get PCR extensions. With SHA1 being considered broken we want avoid SHA1 being used. Ideally by removing support it altogether. In case this is not possible for backward compatibility reasons at least have it disabled by default. So swtpm_setup not enabling the SHA1 bank by default is certainly a good idea and a move into the right direction (independent from the patch #4 discussion). Didn't do much testing yet to see whenever removing SHA1 support altogether trips up operating systems. > - Since TPM 1.2 is still supported we need to add a TPM menu for it as well > using this patch here. I would put this under the TPM1_ENABLE config option > since having TPM 1.2 support without a menu is quite useless. I can send a > patch for this once this series has gone through. I can pick this up for v2 if you don't mind. take care, Gerd