[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200319161245.GD5122@8bytes.org>
Date: Thu, 19 Mar 2020 17:12:46 +0100
From: Joerg Roedel <joro@...tes.org>
To: Andy Lutomirski <luto@...nel.org>
Cc: X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
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>,
LKML <linux-kernel@...r.kernel.org>,
kvm list <kvm@...r.kernel.org>,
Linux Virtualization <virtualization@...ts.linux-foundation.org>,
Joerg Roedel <jroedel@...e.de>
Subject: Re: [PATCH 42/70] x86/sev-es: Support nested #VC exceptions
On Thu, Mar 19, 2020 at 08:46:36AM -0700, Andy Lutomirski wrote:
> This can't possibly end well. Maybe have a little percpu list of
> GHCBs and make sure there are enough for any possible nesting?
Yeah, it is not entirely robust yet. Without NMI nesting the number of
possible #VC nesting levels should be limited. At least one backup GHCB
pre-allocated is probably a good idea.
> Also, I admit confusion. Isn't the GHCB required to be unencrypted?
> How does that work with kzalloc()?
Yes, but the kzalloc'ed ghcb is just the backup space for the real GHCB,
which is mapped unencrypted. The contents of the unencrypted GHCB is
copied to the backup and restored on return, so that the interrupted #VC
handler finds the GHCB unmodified.
Regards,
Joerg
Powered by blists - more mailing lists