From: Sean Christopherson <seanjc@google.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Eric Biederman <ebiederm@xmission.com>,
x86@kernel.org, kexec@lists.infradead.org,
Joerg Roedel <jroedel@suse.de>,
stable@vger.kernel.org, hpa@zytor.com,
Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Jiri Slaby <jslaby@suse.cz>,
Dan Williams <dan.j.williams@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Juergen Gross <jgross@suse.com>,
Kees Cook <keescook@chromium.org>,
David Rientjes <rientjes@google.com>,
Cfir Cohen <cfir@google.com>, Erdem Aktas <erdemaktas@google.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mike Stunes <mstunes@vmware.com>,
Martin Radev <martin.b.radev@gmail.com>,
Arvind Sankar <nivedita@alum.mit.edu>,
linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 1/2] kexec: Allow architecture code to opt-out at runtime
Date: Thu, 6 May 2021 15:43:23 +0000 [thread overview]
Message-ID: <YJQOmxx1EMUqNpNn@google.com> (raw)
In-Reply-To: <20210506093122.28607-2-joro@8bytes.org>
On Thu, May 06, 2021, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
>
> Allow a runtime opt-out of kexec support for architecture code in case
> the kernel is running in an environment where kexec is not properly
> supported yet.
>
> This will be used on x86 when the kernel is running as an SEV-ES
> guest. SEV-ES guests need special handling for kexec to hand over all
> CPUs to the new kernel. This requires special hypervisor support and
> handling code in the guest which is not yet implemented.
>
> Cc: stable@vger.kernel.org # v5.10+
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
> kernel/kexec.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index c82c6c06f051..d03134160458 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -195,11 +195,25 @@ static int do_kexec_load(unsigned long entry, unsigned long nr_segments,
> * that to happen you need to do that yourself.
> */
>
> +bool __weak arch_kexec_supported(void)
> +{
> + return true;
> +}
> +
> static inline int kexec_load_check(unsigned long nr_segments,
> unsigned long flags)
> {
> int result;
>
> + /*
> + * The architecture may support kexec in general, but the kernel could
> + * run in an environment where it is not (yet) possible to execute a new
> + * kernel. Allow the architecture code to opt-out of kexec support when
> + * it is running in such an environment.
> + */
> + if (!arch_kexec_supported())
> + return -ENOSYS;
This misses kexec_file_load. Also, is a new hook really needed? E.g. the
SEV-ES check be shoved into machine_kexec_prepare(). The downside is that we'd
do a fair amount of work before detecting failure, but that doesn't seem hugely
problematic.
> +
> /* We only trust the superuser with rebooting the system. */
> if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
> return -EPERM;
> --
> 2.31.1
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Eric Biederman <ebiederm@xmission.com>,
x86@kernel.org, kexec@lists.infradead.org,
Joerg Roedel <jroedel@suse.de>,
stable@vger.kernel.org, hpa@zytor.com,
Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Jiri Slaby <jslaby@suse.cz>,
Dan Williams <dan.j.williams@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Juergen Gross <jgross@suse.com>,
Kees Cook <keescook@chromium.org>,
David Rientjes <rientjes@google.com>,
Cfir Cohen <cfir@google.com>, Erdem Aktas <erdemaktas@google.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mike Stunes <mstunes@vmware.com>,
Martin Radev <martin.b.radev@gmail.com>,
Arvind Sankar <nivedita@alum.mit.edu>,
linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 1/2] kexec: Allow architecture code to opt-out at runtime
Date: Thu, 6 May 2021 15:43:23 +0000 [thread overview]
Message-ID: <YJQOmxx1EMUqNpNn@google.com> (raw)
In-Reply-To: <20210506093122.28607-2-joro@8bytes.org>
On Thu, May 06, 2021, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
>
> Allow a runtime opt-out of kexec support for architecture code in case
> the kernel is running in an environment where kexec is not properly
> supported yet.
>
> This will be used on x86 when the kernel is running as an SEV-ES
> guest. SEV-ES guests need special handling for kexec to hand over all
> CPUs to the new kernel. This requires special hypervisor support and
> handling code in the guest which is not yet implemented.
>
> Cc: stable@vger.kernel.org # v5.10+
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
> kernel/kexec.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index c82c6c06f051..d03134160458 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -195,11 +195,25 @@ static int do_kexec_load(unsigned long entry, unsigned long nr_segments,
> * that to happen you need to do that yourself.
> */
>
> +bool __weak arch_kexec_supported(void)
> +{
> + return true;
> +}
> +
> static inline int kexec_load_check(unsigned long nr_segments,
> unsigned long flags)
> {
> int result;
>
> + /*
> + * The architecture may support kexec in general, but the kernel could
> + * run in an environment where it is not (yet) possible to execute a new
> + * kernel. Allow the architecture code to opt-out of kexec support when
> + * it is running in such an environment.
> + */
> + if (!arch_kexec_supported())
> + return -ENOSYS;
This misses kexec_file_load. Also, is a new hook really needed? E.g. the
SEV-ES check be shoved into machine_kexec_prepare(). The downside is that we'd
do a fair amount of work before detecting failure, but that doesn't seem hugely
problematic.
> +
> /* We only trust the superuser with rebooting the system. */
> if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
> return -EPERM;
> --
> 2.31.1
>
next prev parent reply other threads:[~2021-05-06 15:43 UTC|newest]
Thread overview: 22+ 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 ` Joerg Roedel
2021-05-06 9:31 ` [PATCH 1/2] kexec: Allow architecture code to opt-out at runtime Joerg Roedel
2021-05-06 9:31 ` Joerg Roedel
2021-05-06 15:43 ` Sean Christopherson [this message]
2021-05-06 15:43 ` Sean Christopherson
2021-05-06 18:24 ` Joerg Roedel
2021-05-06 18:24 ` Joerg Roedel
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 9:31 ` Joerg Roedel
2021-05-06 17:42 ` Eric W. Biederman
2021-05-06 17:42 ` Eric W. Biederman
2021-05-06 17:42 ` Eric W. Biederman
2021-05-06 18:41 ` Joerg Roedel
2021-05-06 18:41 ` Joerg Roedel
2021-05-06 18:41 ` Joerg Roedel
2021-05-06 18:59 ` Eric W. Biederman
2021-05-06 18:59 ` Eric W. Biederman
2021-05-06 18:59 ` Eric W. Biederman
2021-05-06 20:41 ` Joerg Roedel
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=YJQOmxx1EMUqNpNn@google.com \
--to=seanjc@google.com \
--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=jroedel@suse.de \
--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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.