From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F0BF2CED632 for ; Wed, 9 Oct 2024 09:11:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zoHDmU4zT3gPY/eaO+0Btiwya893UBUlgLirHtSQMdQ=; b=Ur5atRo8xaMoVo LILhYIkv+axC3pzWNT+pr1oAZCHM3TKiw85zsCJY5svBfl89Dy1df3S1TdmHNeBrem+3odkTNzAtl pM1jtz8oedx6RYT7EzzQT4tcbcPbNpw7npV+TDFR+gc64sEWoRpWhDo8LCgi1FXpUCwk4ILk2Yi9N h0haMi9l6r+eHwV/1wzDYjZDoiIthSq7ZU/s2i5EL6aJCpNGFRsRnaACloLB9sYUbb+KgAs2Uw05q SnD1n9UdpXaIdMOtsdWX5l8UsMc8VnzdRMt75c6R5M0k/wnRiwZVtLd0vR7K8jTMJgjlZdyHnKSOR Jf8jK9GxlG43ckozZpIA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1sySj3-00000008c6v-2iNr; Wed, 09 Oct 2024 09:11:21 +0000 Received: from the.earth.li ([2a00:1098:86:4d:c0ff:ee:15:900d]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1sySj1-00000008c4v-2FNE for kexec@lists.infradead.org; Wed, 09 Oct 2024 09:11:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=earth.li; s=the; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject: Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=41lRgjq+jYVfy53InEiK/LxoafTTsLIwL+NynDjl2xU=; b=NsMO4m1B4aGFYZt9fC4X1CKAiW MIzvs2ZjbL6wZcQDQAOEs1GaikWr5p2AMSFZJxsBGsVRSjp96nvv3M5MX2hIaU5JWNtoh8I75TKyU Z9nj0Wls79/pybLaeBOEJzIGNMB762OnaquwigElHpZech5HnZZMoyAjviXzqId1ygTG7QYOYIS0p lgI+TDFByXZFiYyPWiVlYNV1kURd7gMYyXUCwMGQr3xFJHzRpMNse+ocTUx8qmwtaMWhbWZMPITXX 1aKA62WK/9jKLMx8JtQYtdQaPs5lCdUC748kGa+S1dijJB65QTQmjxAbsHvHqLi4aAGjB4yMH31zW 1zMVnTUw==; Received: from noodles by the.earth.li with local (Exim 4.96) (envelope-from ) id 1sySif-0032Cb-0j; Wed, 09 Oct 2024 10:10:57 +0100 Date: Wed, 9 Oct 2024 10:10:57 +0100 From: Jonathan McDowell To: Ard Biesheuvel Cc: "Eric W. Biederman" , James Bottomley , Breno Leitao , Usama Arif , linux-efi@vger.kernel.org, kexec@lists.infradead.org, bhe@redhat.com, vgoyal@redhat.com, tglx@linutronix.de, dave.hansen@linux.intel.com, x86@kernel.org, linux-kernel@vger.kernel.org, rmikey@meta.com, gourry@gourry.net, linux-integrity@vger.kernel.org Subject: Re: [RFC] efi/tpm: add efi.tpm_log as a reserved region in 820_table_firmware Message-ID: References: <20240912-wealthy-gabby-tamarin-aaba3c@leitao> <20240913-careful-maroon-crab-8a0541@leitao> <5c525fe8f33fffebc0d275086cc7484e309dfae0.camel@HansenPartnership.com> <87o74n5p05.fsf@email.froward.int.ebiederm.org> <874j6e482p.fsf@email.froward.int.ebiederm.org> <87setx3b8l.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241009_021119_677148_48823568 X-CRM114-Status: GOOD ( 33.44 ) X-BeenThere: kexec@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+kexec=archiver.kernel.org@lists.infradead.org On Wed, Sep 18, 2024 at 09:36:06AM +0200, Ard Biesheuvel wrote: > On Wed, 18 Sept 2024 at 05:14, Eric W. Biederman wrote: > > Ard Biesheuvel writes: > > > On Tue, 17 Sept 2024 at 17:24, Eric W. Biederman wrote: > > >> Ard Biesheuvel writes: > > >> This should not be the kexec-on-panic kernel as that runs in memory > > >> that is reserved solely for it's own use. So we are talking something > > >> like using kexec as a bootloader. > > > > > > kexec as a bootloader under TPM based measured boot will need to do a > > > lot more than pass the firmware's event log to the next kernel. I'd > > > expect a properly engineered kexec to replace this table entirely, and > > > include the hashes of the assets it has loaded and measured into the > > > respective PCRs. > > > > > > But let's stick to solving the actual issue here, rather than > > > philosophize on how kexec might work in this context. > > > > I am fine with that. The complaint I had seen was that the table was > > being corrupted and asking how to solve that. It seems I haven't read > > the part of the conversation where it was made clear that no one wants > > the tpm_log after kexec. > > > It was not made clear, that is why I raised the question. I argued > that the TPM log has limited utility after a kexec, given that we will > be in one of two situations: > - the kexec boot chain cares about the TPM and measured boot, and will > therefore have extended the TPM's PCRs and the TPM log will be out of > sync; > - the kexec boot chain does not care, and so there is no point in > forwarding the TPM log. > > Perhaps there is a third case where kdump wants to inspect the TPM log > that the crashed kernel accessed? But this is rather speculative. Generally the kernel/host OS and the firmware are touching different PCRs in the TPM. The firmware eventlog covers what the firmware/bootloader measured; itself, option ROMs, secure boot details, bootloader, initial kernel/initrd (if we're talking grub as the initial bootloader). These details are not changed by a kexec, and provide the anchor of the software trust chain. A kexec'd kernel will generally not touch the same PCRs. The primary way I know to carry kexec measurements / logs over to new kernels is using IMA, which will be configured to use one of the later PCRs (default of 10). That means that the firmware event log is still completely valid to subsequent kernels, and is still required to validate the firmware/bootloader trust chain. You then probably _also_ want to make use of the IMA log to validate the kexec'd kernel chain, but that's separate. > > If someone wants the tpm_log then we need to solve this problem. > Agreed. There's a real requirement and use for kexec'd kernels to be able to continue to access the firmware TPM event log; to the extent that there are also patches floating around to have this carried over via device tree on non-UEFI platforms. J. -- Avoid temporary variables and strange women. This .sig brought to you by the letter U and the number 37 Product of the Republic of HuggieTag _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec