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 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 3A7DBC43460 for ; Thu, 6 May 2021 19:00:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 11FD8610D2 for ; Thu, 6 May 2021 19:00:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234076AbhEFTA6 (ORCPT ); Thu, 6 May 2021 15:00:58 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:53778 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233314AbhEFTA4 (ORCPT ); Thu, 6 May 2021 15:00:56 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lejDx-006IlB-FL; Thu, 06 May 2021 12:59:49 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=fess.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lejDv-007wor-20; Thu, 06 May 2021 12:59:48 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Joerg Roedel Cc: Joerg Roedel , x86@kernel.org, kexec@lists.infradead.org, stable@vger.kernel.org, hpa@zytor.com, Andy Lutomirski , Dave Hansen , Peter Zijlstra , Jiri Slaby , Dan Williams , Tom Lendacky , Juergen Gross , Kees Cook , David Rientjes , Cfir Cohen , Erdem Aktas , Masami Hiramatsu , Mike Stunes , Sean Christopherson , Martin Radev , Arvind Sankar , linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org References: <20210506093122.28607-1-joro@8bytes.org> <20210506093122.28607-3-joro@8bytes.org> Date: Thu, 06 May 2021 13:59:42 -0500 In-Reply-To: (Joerg Roedel's message of "Thu, 6 May 2021 20:41:05 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1lejDv-007wor-20;;;mid=;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+QSetsVGHHRPIqFsnfIS69iprRKQZBDtk= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH 2/2] x86/kexec/64: Forbid kexec when running as an SEV-ES guest X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Joerg Roedel writes: > 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. Why does it need that? Would it not make sense to instead teach kexec how to pass a cpu from one kernel to another. We could use that everywhere. Even the kexec-on-panic case should work as even in that case we have to touch the cpus as they go down. The hardware simply worked well enough that it hasn't mattered enough for us to do something like that, but given that we need to do something anyway. It seems like it would make most sense do something that will work everywhere, and does not introduce unnecessary dependencies on hypervisors. >> 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. I can understand temporarily disabling the functionality. >> 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. Why does bringing up a cpu need hypervisor support? I understand why we can't do what we do currently, but that doesn't seem to preclude doing something without hypervisor support. Eric