| Message ID | 20200211135256.24617-40-joro@8bytes.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Linux as SEV-ES Guest Support | expand |
On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel <joro@8bytes.org> wrote: > > From: Joerg Roedel <jroedel@suse.de> > > Send SIGBUS to the user-space process that caused the #VC exception > instead of killing the machine. Also ratelimit the error messages so > that user-space can't flood the kernel log. What would cause this? CPUID? Something else? --Andy
On Tue, Feb 11, 2020 at 02:47:05PM -0800, Andy Lutomirski wrote: > On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel <joro@8bytes.org> wrote: > > > > From: Joerg Roedel <jroedel@suse.de> > > > > Send SIGBUS to the user-space process that caused the #VC exception > > instead of killing the machine. Also ratelimit the error messages so > > that user-space can't flood the kernel log. > > What would cause this? CPUID? Something else? Yes, CPUID, RDTSC(P) and, most importantly, user-space mapping some IO space an accessing it, causing MMIO #VC exceptions. Especially the MMIO case has so many implications that it will not be supported at the moment. Imagine for example MMIO accesses by 32bit user-space with non-standard, non-zero based code and data segments. Or user-space changing the instruction bytes between when the #VC exception is raised and when the handler parses the instruction. Lots of checks are needed to make this work securely, and the complexity of this is not worth it at this time. Regards, Joerg
diff --git a/arch/x86/kernel/sev-es.c b/arch/x86/kernel/sev-es.c index f5bff4219f6f..d128a9397639 100644 --- a/arch/x86/kernel/sev-es.c +++ b/arch/x86/kernel/sev-es.c @@ -254,16 +254,16 @@ dotraplinkage void do_vmm_communication(struct pt_regs *regs, unsigned long exit finish_insn(&ctxt); break; case ES_UNSUPPORTED: - pr_emerg("Unsupported exit-code 0x%02lx in early #VC exception (IP: 0x%lx)\n", - exit_code, regs->ip); + pr_err_ratelimited("Unsupported exit-code 0x%02lx in early #VC exception (IP: 0x%lx)\n", + exit_code, regs->ip); goto fail; case ES_VMM_ERROR: - pr_emerg("PANIC: Failure in communication with VMM (exit-code 0x%02lx IP: 0x%lx)\n", - exit_code, regs->ip); + pr_err_ratelimited("Failure in communication with VMM (exit-code 0x%02lx IP: 0x%lx)\n", + exit_code, regs->ip); goto fail; case ES_DECODE_FAILED: - pr_emerg("PANIC: Failed to decode instruction (exit-code 0x%02lx IP: 0x%lx)\n", - exit_code, regs->ip); + pr_err_ratelimited("PANIC: Failed to decode instruction (exit-code 0x%02lx IP: 0x%lx)\n", + exit_code, regs->ip); goto fail; case ES_EXCEPTION: forward_exception(&ctxt); @@ -278,10 +278,24 @@ dotraplinkage void do_vmm_communication(struct pt_regs *regs, unsigned long exit return; fail: - show_regs(regs); + if (user_mode(regs)) { + /* + * Do not kill the machine if user-space triggered the + * exception. Send SIGBUS instead and let user-space deal with + * it. + */ + force_sig_fault(SIGBUS, BUS_OBJERR, (void __user *)0); + } else { + /* Show some debug info */ + show_regs(regs); - while (true) - halt(); + /* Ask hypervisor to terminate */ + terminate(GHCB_SEV_ES_REASON_GENERAL_REQUEST); + + /* If that fails and we get here - just halt the machine */ + while (true) + halt(); + } } int __init boot_vc_exception(struct pt_regs *regs)