From: Joerg Roedel <[email protected]>
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: [email protected] # v5.10+
Signed-off-by: Joerg Roedel <[email protected]>
---
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;
+
/* We only trust the superuser with rebooting the system. */
if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
return -EPERM;
--
2.31.1
On Thu, May 06, 2021, Joerg Roedel wrote:
> From: Joerg Roedel <[email protected]>
>
> 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: [email protected] # v5.10+
> Signed-off-by: Joerg Roedel <[email protected]>
> ---
> 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
>
On Thu, May 06, 2021 at 03:43:23PM +0000, Sean Christopherson wrote:
> This misses kexec_file_load.
Right, thanks, I will fix that in the next version.
> 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.
That could work, but I think its more user-friendly to just claim that
the syscalls are not supported at all.
Regards,
Joerg