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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B443C7EE2C for ; Tue, 16 May 2023 00:41:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245509AbjEPAly (ORCPT ); Mon, 15 May 2023 20:41:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230343AbjEPAlx (ORCPT ); Mon, 15 May 2023 20:41:53 -0400 Received: from sender3-of-o57.zoho.com (sender3-of-o57.zoho.com [136.143.184.57]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5CE8430FD; Mon, 15 May 2023 17:41:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684197665; cv=none; d=zohomail.com; s=zohoarc; b=XqR1E9WYKCH5zE0xzfY8q4o8hGEYSOcK4tGK8Q2iZaxhLN15Hn9ctmHY8DtzrsYk2A5JcUeaikJSlwkgyABpztvRWjet1OYjyGyL7URMv+qwqpyjSYxr5HsuEOVzD0Xal0X8RUmyepOxiwtPHvYTxubO8ftpTOFqd94yQnxZSGQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1684197665; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=x9E1sPNjs8TnJyDDWuPW+7RruRAouFKTsWP7ZU6lxAw=; b=edBBMwqoIA3px3KRjoqOeVRGIRAKy1Ii6k5VvgFlZblTWvXISxJ1iWXnImdMo8Z/jsjvfy/JPv/0fwx9Up2i0+vuBxSIPlzcAfciWFQyaK2FjPCqIwH/tjXIHcBVW1csLV8OOcA9IABP7hzKJhzpdhsMssnbz7X4BgC83UfqkGQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@apertussolutions.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1684197665; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=x9E1sPNjs8TnJyDDWuPW+7RruRAouFKTsWP7ZU6lxAw=; b=KkBrhxus1IChftrmWFiE0iWqNP8pwvcEA93j1NsBljZB12Dwn/pFRs9ba7CJ9Wc7 edP2pGXBARtnJM2FPzweZ/GrpdlaMrUSCdjtpbMPbNg2rK5PpKzF9po1PYMenL2dJZy M3Z+MoI/+mmQL2JgJ9L9p3qb/TwugPj5kW90GVqc= Received: from [10.10.1.128] (static-72-81-132-2.bltmmd.fios.verizon.net [72.81.132.2]) by mx.zohomail.com with SMTPS id 1684197664523566.236879037264; Mon, 15 May 2023 17:41:04 -0700 (PDT) Message-ID: Date: Mon, 15 May 2023 20:41:00 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v6 04/14] x86: Secure Launch Resource Table header file Content-Language: en-US To: Matthew Garrett Cc: Ross Philipson , 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, 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 References: <20230504145023.835096-1-ross.philipson@oracle.com> <20230504145023.835096-5-ross.philipson@oracle.com> <20230512105554.GB14461@srcf.ucam.org> <30d5891d-4747-8d67-2667-ff07628740bd@apertussolutions.com> <20230515212206.GA2162@srcf.ucam.org> From: "Daniel P. Smith" In-Reply-To: <20230515212206.GA2162@srcf.ucam.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On 5/15/23 17:22, Matthew Garrett wrote: > On Mon, May 15, 2023 at 05:15:15PM -0400, Daniel P. Smith wrote: >> On 5/12/23 06:55, Matthew Garrett wrote: >>> On Thu, May 04, 2023 at 02:50:13PM +0000, Ross Philipson wrote: >>> >>>> +#define SLR_TABLE_MAGIC 0x4452544d >>> >>> From convention I'd expect this to be 0x534c5254, but not really an >>> issue. >> >> Apologies, but which convention? > > Tables in ACPI and UEFI tend to have magic that corresponds to their > name, so a table called SLRT would tend to have magic that matches the > ASCII values for that. In this case the SLRT has DRTM as its magic, > which is a touch unexpected. While the SLRT is meant for UEFI and non-UEFI environments, DRTM is definitely a hold over when we started this and you are correct, probably not the best choice. In fact, I agree that SLRT is a far better magic. We will update the spec and fix it in the series. >>> Oof. Having the kernel know about bootloaders has not worked out super >>> well for us in the past. If someone writes a new bootloader, are they >>> unable to Secure Launch any existing kernels? The pragmatic thing for >>> them to do would be to just pretend they're grub, which kind of defeats >>> the point of having this definition... >> >> Actually, this is not for making the kernel know about bootloaders. This is >> dealing with the challenge created when the preamble was split for efi-stub, >> and similar use cases, where what sets up the preamble, ie. the bootloader, >> is separate from what invokes the dynamic launch, ie. the DLE handler. The >> reality is that even in the simplest implementation of the DLE handler, a >> remnant of GRUB for call back from efi-stub, there is information that is >> needed to cross the gap. > > What if I don't use grub, but use something that behaves equivalently? > Which value should be used here? Generally we would request that the bootloader submit a request to register for a value to be reserved in the spec. That aside, the intent here is to allow for the possibility for the DLE handler to be independent from the bootloader, but this does not have to be this way. If a non-open entity decides to produce their own implementation, they can freely use a unallocated value at their own risk that it could be allocated to another bootloader in the future. Though in this scenario it likely would not matter as the non-open DLE handler would only be present when the non-open bootloader was present. >> We wrote the TrenchBoot Secure Launch general spec [1] with as much >> forethought as possible for the target environments. Specifically, the >> desire is to have a common approach for x86 (Intel and AMD), Arm, and >> perhaps down the road the POWER arch. In particular, I do not believe there >> is anything in the Arm DRTM beta spec that prohibits a mixed 32/64 bit >> environment. In the end it is better to for the spec to be safe for those >> environments then having to make changes to the spec later down the road. > > Ok. Thank you for the review! v/r, dps 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 3E8EFC77B75 for ; Tue, 16 May 2023 00:41:35 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=j4L+M2L1RU9CbavxRyxs4KlHL4xsMw+nYEeUcFfgo8c=; b=zyi+UH1wTA7Tyl Mxqa/O/6vHlsRKze4r4LWiT5yKuC8tMfqhPz0hAwPXiTKyvtV/2oIB+6LjhHgBEpsRER/Sx2ccRby io8KKMfE+gVouwzOzzfTJ0erN1ABC61Dc4qkFbTnLqosjU2Bx9s0pIGfiECHh5KpqcgakNb1Wca9b EmJ5maEI0AHxl1xlI2/gK2rnVHH6VlxyhdLeCAPDl2ODRKeSIXuYbdyxT2+zsqUWSNnTa3BNOiZc+ TJFkKGlpdUitktTBJlQ9ZXh9u2Yv8CV0v0epmY3JGpJS2YAVKFrBmyeHWeJZRrSI5CbsldAhN/vQ9 sIpkxFAkahrcrphA0yGw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pyikn-003xxn-3B; Tue, 16 May 2023 00:41:25 +0000 Received: from sender4-of-o50.zoho.com ([136.143.188.50]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pyikl-003xwh-1Z for kexec@lists.infradead.org; Tue, 16 May 2023 00:41:24 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1684197665; cv=none; d=zohomail.com; s=zohoarc; b=XqR1E9WYKCH5zE0xzfY8q4o8hGEYSOcK4tGK8Q2iZaxhLN15Hn9ctmHY8DtzrsYk2A5JcUeaikJSlwkgyABpztvRWjet1OYjyGyL7URMv+qwqpyjSYxr5HsuEOVzD0Xal0X8RUmyepOxiwtPHvYTxubO8ftpTOFqd94yQnxZSGQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1684197665; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=x9E1sPNjs8TnJyDDWuPW+7RruRAouFKTsWP7ZU6lxAw=; b=edBBMwqoIA3px3KRjoqOeVRGIRAKy1Ii6k5VvgFlZblTWvXISxJ1iWXnImdMo8Z/jsjvfy/JPv/0fwx9Up2i0+vuBxSIPlzcAfciWFQyaK2FjPCqIwH/tjXIHcBVW1csLV8OOcA9IABP7hzKJhzpdhsMssnbz7X4BgC83UfqkGQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@apertussolutions.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1684197665; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=x9E1sPNjs8TnJyDDWuPW+7RruRAouFKTsWP7ZU6lxAw=; b=KkBrhxus1IChftrmWFiE0iWqNP8pwvcEA93j1NsBljZB12Dwn/pFRs9ba7CJ9Wc7 edP2pGXBARtnJM2FPzweZ/GrpdlaMrUSCdjtpbMPbNg2rK5PpKzF9po1PYMenL2dJZy M3Z+MoI/+mmQL2JgJ9L9p3qb/TwugPj5kW90GVqc= Received: from [10.10.1.128] (static-72-81-132-2.bltmmd.fios.verizon.net [72.81.132.2]) by mx.zohomail.com with SMTPS id 1684197664523566.236879037264; Mon, 15 May 2023 17:41:04 -0700 (PDT) Message-ID: Date: Mon, 15 May 2023 20:41:00 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v6 04/14] x86: Secure Launch Resource Table header file Content-Language: en-US To: Matthew Garrett Cc: Ross Philipson , 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, 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 References: <20230504145023.835096-1-ross.philipson@oracle.com> <20230504145023.835096-5-ross.philipson@oracle.com> <20230512105554.GB14461@srcf.ucam.org> <30d5891d-4747-8d67-2667-ff07628740bd@apertussolutions.com> <20230515212206.GA2162@srcf.ucam.org> From: "Daniel P. Smith" In-Reply-To: <20230515212206.GA2162@srcf.ucam.org> X-ZohoMailClient: External X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230515_174123_552895_6F706780 X-CRM114-Status: GOOD ( 24.95 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "kexec" Errors-To: kexec-bounces+kexec=archiver.kernel.org@lists.infradead.org On 5/15/23 17:22, Matthew Garrett wrote: > On Mon, May 15, 2023 at 05:15:15PM -0400, Daniel P. Smith wrote: >> On 5/12/23 06:55, Matthew Garrett wrote: >>> On Thu, May 04, 2023 at 02:50:13PM +0000, Ross Philipson wrote: >>> >>>> +#define SLR_TABLE_MAGIC 0x4452544d >>> >>> From convention I'd expect this to be 0x534c5254, but not really an >>> issue. >> >> Apologies, but which convention? > > Tables in ACPI and UEFI tend to have magic that corresponds to their > name, so a table called SLRT would tend to have magic that matches the > ASCII values for that. In this case the SLRT has DRTM as its magic, > which is a touch unexpected. While the SLRT is meant for UEFI and non-UEFI environments, DRTM is definitely a hold over when we started this and you are correct, probably not the best choice. In fact, I agree that SLRT is a far better magic. We will update the spec and fix it in the series. >>> Oof. Having the kernel know about bootloaders has not worked out super >>> well for us in the past. If someone writes a new bootloader, are they >>> unable to Secure Launch any existing kernels? The pragmatic thing for >>> them to do would be to just pretend they're grub, which kind of defeats >>> the point of having this definition... >> >> Actually, this is not for making the kernel know about bootloaders. This is >> dealing with the challenge created when the preamble was split for efi-stub, >> and similar use cases, where what sets up the preamble, ie. the bootloader, >> is separate from what invokes the dynamic launch, ie. the DLE handler. The >> reality is that even in the simplest implementation of the DLE handler, a >> remnant of GRUB for call back from efi-stub, there is information that is >> needed to cross the gap. > > What if I don't use grub, but use something that behaves equivalently? > Which value should be used here? Generally we would request that the bootloader submit a request to register for a value to be reserved in the spec. That aside, the intent here is to allow for the possibility for the DLE handler to be independent from the bootloader, but this does not have to be this way. If a non-open entity decides to produce their own implementation, they can freely use a unallocated value at their own risk that it could be allocated to another bootloader in the future. Though in this scenario it likely would not matter as the non-open DLE handler would only be present when the non-open bootloader was present. >> We wrote the TrenchBoot Secure Launch general spec [1] with as much >> forethought as possible for the target environments. Specifically, the >> desire is to have a common approach for x86 (Intel and AMD), Arm, and >> perhaps down the road the POWER arch. In particular, I do not believe there >> is anything in the Arm DRTM beta spec that prohibits a mixed 32/64 bit >> environment. In the end it is better to for the spec to be safe for those >> environments then having to make changes to the spec later down the road. > > Ok. Thank you for the review! v/r, dps _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec