[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <BD48E405-8E3F-4EEE-A72A-8A7EDCB6A376@amacapital.net>
Date: Tue, 11 Feb 2020 19:48:12 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Joerg Roedel <joro@...tes.org>
Cc: x86@...nel.org, hpa@...or.com, Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Hellstrom <thellstrom@...are.com>,
Jiri Slaby <jslaby@...e.cz>,
Dan Williams <dan.j.williams@...el.com>,
Tom Lendacky <Thomas.Lendacky@....com>,
Juergen Gross <JGross@...e.com>,
Kees Cook <keescook@...omium.org>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
Joerg Roedel <jroedel@...e.de>
Subject: Re: [RFC PATCH 00/62] Linux as SEV-ES Guest Support
> On Feb 11, 2020, at 5:53 AM, Joerg Roedel <joro@...tes.org> wrote:
>
>
> * Putting some NMI-load on the guest will make it crash usually
> within a minute
Suppose you do CPUID or some MMIO and get #VC. You fill in the GHCB to ask for help. Some time between when you start filling it out and when you do VMGEXIT, you get NMI. If the NMI does
its own GHCB access [0], it will clobber the outer #VC’a state, resulting in a failure when VMGEXIT happens. There’s a related failure mode if the NMI is after the VMGEXIT but before the result is read.
I suspect you can fix this by saving the GHCB at the beginning of do_nmi and restoring it at the end. This has the major caveat that it will not work if do_nmi comes from user mode and schedules, but I don’t believe this can happen.
[0] Due to the NMI_COMPLETE catastrophe, there is a 100% chance that this happens.
Powered by blists - more mailing lists