From: Joerg Roedel <jroedel@suse.de>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: kvm@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
virtualization@lists.linux-foundation.org,
Arvind Sankar <nivedita@alum.mit.edu>,
hpa@zytor.com, Jiri Slaby <jslaby@suse.cz>,
Joerg Roedel <joro@8bytes.org>,
x86@kernel.org, David Rientjes <rientjes@google.com>,
Martin Radev <martin.b.radev@gmail.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Kees Cook <keescook@chromium.org>, Cfir Cohen <cfir@google.com>,
linux-coco@lists.linux.dev, Andy Lutomirski <luto@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Juergen Gross <jgross@suse.com>, Mike Stunes <mstunes@vmware.com>,
Sean Christopherson <seanjc@google.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Masami Hiramatsu <mhiramat@kernel.org>,
Erdem Aktas <erdemaktas@google.com>
Subject: Re: [PATCH 2/2] x86/kexec/64: Forbid kexec when running as an SEV-ES guest
Date: Thu, 6 May 2021 20:41:05 +0200 [thread overview]
Message-ID: <YJQ4QTtvG76WpcNf@suse.de> (raw)
In-Reply-To: <m17dkb4v4k.fsf@fess.ebiederm.org>
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
next prev parent reply other threads:[~2021-05-06 18:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-06 9:31 [PATCH 0/2] x86: Disable kexec for SEV-ES guests Joerg Roedel
2021-05-06 9:31 ` [PATCH 1/2] kexec: Allow architecture code to opt-out at runtime Joerg Roedel
[not found] ` <YJQOmxx1EMUqNpNn@google.com>
2021-05-06 18:24 ` Joerg Roedel
2021-05-06 9:31 ` [PATCH 2/2] x86/kexec/64: Forbid kexec when running as an SEV-ES guest Joerg Roedel
2021-05-06 17:42 ` Eric W. Biederman
2021-05-06 18:41 ` Joerg Roedel [this message]
2021-05-06 18:59 ` Eric W. Biederman
2021-05-06 20:41 ` Joerg Roedel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YJQ4QTtvG76WpcNf@suse.de \
--to=jroedel@suse.de \
--cc=cfir@google.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=ebiederm@xmission.com \
--cc=erdemaktas@google.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=joro@8bytes.org \
--cc=jslaby@suse.cz \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=martin.b.radev@gmail.com \
--cc=mhiramat@kernel.org \
--cc=mstunes@vmware.com \
--cc=nivedita@alum.mit.edu \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=seanjc@google.com \
--cc=stable@vger.kernel.org \
--cc=thomas.lendacky@amd.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).