From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.skyhub.de (unknown [5.9.137.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB19E2FB3 for ; Fri, 25 Jun 2021 14:49:09 +0000 (UTC) Received: from zn.tnic (p200300ec2f0dae0049fb297996de39ad.dip0.t-ipconnect.de [IPv6:2003:ec:2f0d:ae00:49fb:2979:96de:39ad]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id C72C91EC0595; Fri, 25 Jun 2021 16:48:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1624632537; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=ENHDjrvHsrLVlBAdGgAmMkR2KuwDaPAvXCPilbbBf7A=; b=LSXOwsdhUEbhG7vaRlM3tlHXlIL2v/KBN+RiZWsEAiLf8BjJ9w+dKv3EgevZlFNctBQ91L kihWVCGWyB74ZmIbVG0UFqLQZu5TOOgdIAz2KLjcURGT5bgtWTYQC9esnD34CSJRSM4rZm Ez3S06oseaAAUrkfLls9v8mOe0j+Sqk= Date: Fri, 25 Jun 2021 16:48:53 +0200 From: Borislav Petkov To: Michael Roth Cc: "Kuppuswamy, Sathyanarayanan" , Dave Hansen , Brijesh Singh , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , tony.luck@intel.com, npmccallum@redhat.com Subject: Re: [PATCH Part1 RFC v3 20/22] x86/boot: Add Confidential Computing address to setup_header Message-ID: References: <15568c80-c9a9-5602-d940-264af87bed98@amd.com> <162442264313.98837.16983159316116149849@amd.com> <20210624031911.eznpkbgjt4e445xj@amd.com> <20210624123447.zbfkohbtdusey66w@amd.com> <20210624141111.pzvb6gk5lzfelx26@amd.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210624141111.pzvb6gk5lzfelx26@amd.com> On Thu, Jun 24, 2021 at 09:11:11AM -0500, Michael Roth wrote: > We don't need anything in setup_data/setup_header. We can access the > CC blob table via EFI config table. However, parsing EFI config table > early in uncompressed/proper kernel has the complications I mentioned in my > initial response. So since you want to parse the EFI table in the boot stage, that tells me that you need the blob in the early, boot kernel too, correct? > This is where using a new boot_params field comes into > play (similar to acpi_rsdp_addr), so boot/compressed can pass > uncompressed/proper kernel a pointer to the pre-parsed CC blob so it doesn't > need to re-parse EFI config table during early boot. Ack. > For non-EFI case: > > We need a "proper" mechanism that bootloaders can use. My > understanding is this would generally be via setup_data or > setup_header, and that a direct boot_params field would be frowned > upon. So, you need to pass only an address, right? How workable would it be if you had a cmdline option: cc_blob_address=0xb1a with which you tell the kernel where that thing is? Because then you can use this in both cases - EFI and !EFI. Or is this blob platform-dependent and the EFI table contains it and something needs to get it out of there, even if it were a user to type in the cmdline cc_blob_address or some script when it comes to containers...? In any case, setup_data is kinda the generic way to pass arbitrary data to the kernel so in this case, you can prioritize the EFI table in the EFI case and fall back to setup_data if there's no EFI table... > So your understanding of the situation seems correct. > > By bringing up the non-EFI case I only meant to point out that by using a > field in setup_header, we could re-use that field for the EFI case as well, > and wouldn't need a seperate boot_params field to handle the > boot/compressed->uncompressed passing of the pre-parsed CC blob address > in the EFI case. But I don't think it makes a big difference as far as > my stuff goes at least. Maybe for TDX though this needs more thought. Yah, let's see what requirements they'd come back with. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette