| Message ID | 20210506093122.28607-2-joro@8bytes.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: Disable kexec for SEV-ES guests | expand |
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 >
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
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;