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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,URIBL_RED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE0C2C433B4 for ; Thu, 6 May 2021 18:41:14 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 60E066121F for ; Thu, 6 May 2021 18:41:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 60E066121F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=virtualization-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2610483D0E; Thu, 6 May 2021 18:41:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV1C2qwJIGaX; Thu, 6 May 2021 18:41:13 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTP id CDA8083D1B; Thu, 6 May 2021 18:41:12 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id A8D97C000E; Thu, 6 May 2021 18:41:12 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 64DBDC0001 for ; Thu, 6 May 2021 18:41:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 4654F615D1 for ; Thu, 6 May 2021 18:41:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4JxKJt-5O2P for ; Thu, 6 May 2021 18:41:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by smtp3.osuosl.org (Postfix) with ESMTPS id 5EFE361593 for ; Thu, 6 May 2021 18:41:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 8E651B186; Thu, 6 May 2021 18:41:08 +0000 (UTC) Date: Thu, 6 May 2021 20:41:05 +0200 From: Joerg Roedel To: "Eric W. Biederman" Subject: Re: [PATCH 2/2] x86/kexec/64: Forbid kexec when running as an SEV-ES guest Message-ID: References: <20210506093122.28607-1-joro@8bytes.org> <20210506093122.28607-3-joro@8bytes.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kvm@vger.kernel.org, Peter Zijlstra , Dave Hansen , virtualization@lists.linux-foundation.org, Arvind Sankar , hpa@zytor.com, Jiri Slaby , Joerg Roedel , x86@kernel.org, David Rientjes , Martin Radev , Tom Lendacky , Kees Cook , Cfir Cohen , linux-coco@lists.linux.dev, Andy Lutomirski , Dan Williams , Juergen Gross , Mike Stunes , Sean Christopherson , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Masami Hiramatsu , Erdem Aktas X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" On Thu, May 06, 2021 at 12:42:03PM -0500, Eric W. Biederman wrote: > I don't understand this. > > Fundamentally kexec is about doing things more or less inspite of > what the firmware is doing. > > I don't have any idea what a SEV-ES is. But the normal x86 boot doesn't > do anything special. Is cross cpu IPI emulation buggy? Under SEV-ES the normal SIPI-based sequence to re-initialize a CPU does not work anymore. An SEV-ES guest is a special virtual machine where the hardware encrypts the guest memory and the guest register state. The hypervisor can't make any modifications to the guests registers at runtime. Therefore it also can't emulate a SIPI sequence and reset the vCPU. The guest kernel has to reset the vCPU itself and hand it over from the old kernel to the kexec'ed kernel. This isn't currently implemented and therefore kexec needs to be disabled when running as an SEV-ES guest. Implementing this also requires an extension to the guest-hypervisor protocol (the GHCB Spec[1]) which is only available in version 2. So a guest running on a hypervisor supporting only version 1 will never properly support kexec. > What is the actual problem you are trying to avoid? Currently, if someone tries kexec in an SEV-ES guest, the kexec'ed kernel will only be able to bring up the boot CPU, not the others. The others will wake up with the old kernels CPU state in the new kernels memory and do undefined things, most likely triple-fault because their page-table is not existent anymore. So since kexec currently does not work as expected under SEV-ES, it is better to hide it until everything is implemented so it can do what the user expects. > And yes for a temporary hack the suggestion of putting code into > machine_kexec_prepare seems much more reasonable so we don't have to > carry special case infrastructure for the forseeable future. As I said above, for protocol version 1 it will stay disabled, so it is not only a temporary hack. Regards, Joerg [1] https://developer.amd.com/wp-content/resources/56421.pdf _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization