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 DF957C7EE2A for ; Fri, 12 May 2023 11:26:31 +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=xpvhYtEZJoySQfJXzbN0zEEmW/6cx8TBAkNzWTCaIqg=; b=2gKadtZZxNy1HF NcpD8S6KPoV8DZs3UCBOavbGxhUsyAI8Y0sxf22yzoakW39DHTzTTvcZLhpGaolPRM0/IZuKlC1sK kcreNeW189HFPK1Nede9QrpeJKk7pgXQif1SkeX3L1S4idGFBfDsj3QHtOaYWyLCafhxkep2BkBKt SebA/lyDf10Lz515o5DDUGbmyLhlO2V/QQlz1mXPrmkauhcvZzF/LUHJUcUYDptLrw2FPp/zvP+ol OVKTYS3EHpQLUH+vcebGQ8ynZ86G0Q3ElX67oXzggjY5qGeTimWe5hDz/MXV28409pdnnS3znWx5n zVij+WBx58j3RyJqfJ6g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pxQup-00Bofx-2d; Fri, 12 May 2023 11:26:27 +0000 Received: from irc.codon.org.uk ([2a00:1098:84:22e::2] helo=cavan.codon.org.uk) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pxQum-00BofE-2x for kexec@lists.infradead.org; Fri, 12 May 2023 11:26:26 +0000 Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 3036142527; Fri, 12 May 2023 12:26:23 +0100 (BST) Date: Fri, 12 May 2023 12:26:23 +0100 From: Matthew Garrett To: Ross Philipson Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org, linux-crypto@vger.kernel.org, iommu@lists.linux-foundation.org, kexec@lists.infradead.org, linux-efi@vger.kernel.org, dpsmith@apertussolutions.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, ardb@kernel.org, James.Bottomley@hansenpartnership.com, luto@amacapital.net, nivedita@alum.mit.edu, kanth.ghatraju@oracle.com, trenchboot-devel@googlegroups.com Subject: Re: [PATCH v6 07/14] x86: Secure Launch kernel early boot stub Message-ID: <20230512112623.GE14461@srcf.ucam.org> References: <20230504145023.835096-1-ross.philipson@oracle.com> <20230504145023.835096-8-ross.philipson@oracle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230504145023.835096-8-ross.philipson@oracle.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230512_042625_082713_D375C2FD X-CRM114-Status: GOOD ( 13.26 ) 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 Thu, May 04, 2023 at 02:50:16PM +0000, Ross Philipson wrote: > +static void sl_find_event_log(struct slr_table *slrt) If this is called after the EFI stub then we're presumably post-ExitBootServices and we're copied the TPM event log into a configuration table so it's available to the runtime kernel. That also means that we should be adding all further measurements to the Final Events Table rather than the initial event log. How's that handled here, both in terms of ensuring further events (generated by firmware or by us) get added to the right place, and in terms of ensuring the event logs the kernel has later on were covered appropriately? Or is the SL event log an entirely different thing that can be merged in later because it only covers the DRTM PCRs? > +static void sl_extend_setup_data(struct slr_policy_entry *entry) > +{ > + struct setup_data *data; > + > + /* > + * Measuring the boot params measured the fixed e820 memory map. > + * Measure any setup_data entries including e820 extended entries. > + */ > + data = (struct setup_data *)(unsigned long)entry->entity; > + while (data) > + data = sl_handle_setup_data(data, entry); > +} Is e820 sufficient here? There are cases where we use the EFI memory map directly (sorry), but I don't know if any of them are relevant to DRTM outcomes. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec