linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Brijesh Singh <brijesh.singh@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, linux-efi@vger.kernel.org,
	platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev,
	linux-mm@kvack.org, linux-crypto@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Joerg Roedel <jroedel@suse.de>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Sean Christopherson <seanjc@google.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>,
	Andy Lutomirski <luto@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Sergio Lopez <slp@redhat.com>, Peter Gonda <pgonda@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	David Rientjes <rientjes@google.com>,
	Dov Murik <dovmurik@linux.ibm.com>,
	Tobin Feldman-Fitzthum <tobin@ibm.com>,
	Michael Roth <michael.roth@amd.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	tony.luck@intel.com, npmccallum@redhat.com,
	brijesh.ksingh@gmail.com
Subject: Re: [PATCH Part1 RFC v4 08/36] x86/sev: check the vmpl level
Date: Fri, 13 Aug 2021 08:13:20 -0500	[thread overview]
Message-ID: <bd5b8826-ab0b-4f4f-8594-0c7e6232941a@amd.com> (raw)
In-Reply-To: <YRYegqsigZfrbFbk@zn.tnic>


On 8/13/21 2:25 AM, Borislav Petkov wrote:
> On Wed, Jul 07, 2021 at 01:14:38PM -0500, Brijesh Singh wrote:
>> Virtual Machine Privilege Level (VMPL) is an optional feature in the
>> SEV-SNP architecture, which allows a guest VM to divide its address space
>> into four levels. The level can be used to provide the hardware isolated
>> abstraction layers with a VM. The VMPL0 is the highest privilege, and
>> VMPL3 is the least privilege. Certain operations must be done by the VMPL0
>> software, such as:
>>
>> * Validate or invalidate memory range (PVALIDATE instruction)
>> * Allocate VMSA page (RMPADJUST instruction when VMSA=1)
>>
>> The initial SEV-SNP support assumes that the guest kernel is running on
>> VMPL0. Let's add a check to make sure that kernel is running at VMPL0
>> before continuing the boot. There is no easy method to query the current
>> VMPL level, so use the RMPADJUST instruction to determine whether its
>> booted at the VMPL0.
>>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>> ---
>>  arch/x86/boot/compressed/sev.c    | 41 ++++++++++++++++++++++++++++---
>>  arch/x86/include/asm/sev-common.h |  1 +
>>  arch/x86/include/asm/sev.h        |  3 +++
>>  3 files changed, 42 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
>> index 7be325d9b09f..2f3081e9c78c 100644
>> --- a/arch/x86/boot/compressed/sev.c
>> +++ b/arch/x86/boot/compressed/sev.c
>> @@ -134,6 +134,36 @@ static inline bool sev_snp_enabled(void)
>>  	return msr_sev_status & MSR_AMD64_SEV_SNP_ENABLED;
>>  }
>>  
>> +static bool is_vmpl0(void)
>> +{
>> +	u64 attrs, va;
>> +	int err;
>> +
>> +	/*
>> +	 * There is no straightforward way to query the current VMPL level. The
> So this is not nice at all.
>
> And this VMPL level checking can't be part of the GHCB MSR protocol
> because the HV can tell us any VPML level it wants to.
>
> Is there a way to disable VMPL levels and say, this guest should run
> only at VMPL0?

No.

>
> Err, I see SYSCFG[VMPLEn]:
>
> "VMPLEn. Bit 25. Setting this bit to 1 enables the VMPL feature (Section
> 15.36.7 “Virtual Machine Privilege Levels,” on page 580). Software
> should set this bit to 1 when SecureNestedPagingEn is being set to 1.
> Once SecureNestedPagingEn is set to 1, VMPLEn cannot be changed."
>
> But why should that bit be set if SNP is enabled? Can I run a SNP guest
> without VPMLs, i.e, at an implicit VPML level 0?

During the firmware initialization the PSP requires that the VMPLEn is
set. See SNP firmware spec [1] section 8.6. To run the SNP guest you
*must* specify a VMPL level during the vCPU creation.


>
> It says above VPML is optional...

I should not say its optional when we know from the SEV-SNP spec that
VMPLEn must be set to launch SEV-SNP guest. I will fix the description.


> Also, why do you even need to do this at all since the guest controls
> and validates its memory with the RMP? It can simply go and check the
> VMPLs of every page it owns to make sure it is 0.

There is no easy way for a guest to query its VMPL level. The VMPL level
is set during the vCPU creation. The boot cpu is created by the HV and
thus its VMPL level is set by the HV. If HV chooses a lower VMPL level
for the boot CPU then Linux guest will not be able to validate its
memory because the PVALIDATE instruction will cause #GP when the vCPU is
running at !VMPL0. The patch tries to detect the boot CPU VMPL level and
terminate the boot.


>
> Also, if you really wanna support guests with multiple VMPLs, then
> prevalidating its memory is going to be a useless exercise because it'll
> have to go and revalidate the VMPL levels...

We do not need to re-valiate memory when changing to different VMPL
level. The RMPADJUST instruction inside the guest can be used to change
the VMPL permission.


> I also see this:
>
> "When the hypervisor assigns a page to a guest using RMPUPDATE, full
> permissions are enabled for VMPL0 and are disabled for all other VMPLs."
>
> so you get your memory at VMPL0 by the HV. So what is that check for?

Validating the memory is a two step process:

#1 HV adding the memory using the RMPUPDATE in the RMP table.

#2 Guest issuing the PVALIDATE

If guest is not running at VMPL0 then step #2 will cause #GP.  The check
is prevent the #GP and terminate the boot early.

thanks


  reply	other threads:[~2021-08-13 13:13 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-07 18:14 [PATCH Part1 RFC v4 00/36] Add AMD Secure Nested Paging (SEV-SNP) Guest Support Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 01/36] x86/sev: shorten GHCB terminate macro names Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 02/36] x86/sev: Save the negotiated GHCB version Brijesh Singh
2021-08-10  9:17   ` Borislav Petkov
2021-08-10 13:15     ` Brijesh Singh
2021-08-10 10:01   ` Borislav Petkov
2021-08-10 13:17     ` Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 03/36] x86/sev: Add support for hypervisor feature VMGEXIT Brijesh Singh
2021-08-10 11:22   ` Borislav Petkov
2021-08-10 13:39     ` Brijesh Singh
2021-08-10 14:03       ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 04/36] x86/mm: Add sev_feature_enabled() helper Brijesh Singh
2021-07-08  8:50   ` Dr. David Alan Gilbert
2021-07-08  8:53     ` Paolo Bonzini
2021-08-10 11:25   ` Borislav Petkov
2021-08-10 14:57     ` Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 05/36] x86/sev: Define the Linux specific guest termination reasons Brijesh Singh
2021-08-10 11:33   ` Borislav Petkov
2021-08-10 14:59     ` Brijesh Singh
2021-08-10 19:30       ` Tom Lendacky
2021-08-10 21:52         ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 06/36] x86/sev: check SEV-SNP features support Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 07/36] x86/sev: Add a helper for the PVALIDATE instruction Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 08/36] x86/sev: check the vmpl level Brijesh Singh
2021-08-13  7:25   ` Borislav Petkov
2021-08-13 13:13     ` Brijesh Singh [this message]
2021-08-13 15:16       ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 09/36] x86/compressed: Add helper for validating pages in the decompression stage Brijesh Singh
2021-08-13 10:22   ` Borislav Petkov
2021-08-13 14:21     ` Brijesh Singh
2021-08-13 15:19       ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 10/36] x86/compressed: Register GHCB memory when SEV-SNP is active Brijesh Singh
2021-08-13 10:47   ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 11/36] x86/sev: " Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 12/36] x86/sev: Add helper for validating pages in early enc attribute changes Brijesh Singh
2021-08-13 11:13   ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 13/36] x86/kernel: Make the bss.decrypted section shared in RMP table Brijesh Singh
2021-08-13 17:09   ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 14/36] x86/kernel: Validate rom memory before accessing when SEV-SNP is active Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 15/36] x86/mm: Add support to validate memory when changing C-bit Brijesh Singh
2021-08-17 17:27   ` Borislav Petkov
2021-08-17 18:07     ` Brijesh Singh
2021-08-17 18:17       ` Borislav Petkov
2021-08-17 18:18         ` Brijesh Singh
2021-08-17 20:34     ` Brijesh Singh
2021-08-17 20:44       ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 16/36] KVM: SVM: define new SEV_FEATURES field in the VMCB Save State Area Brijesh Singh
2021-08-17 17:54   ` Borislav Petkov
2021-08-17 17:59     ` Borislav Petkov
2021-08-17 18:11     ` Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 17/36] KVM: SVM: Create a separate mapping for the SEV-ES save area Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 18/36] KVM: SVM: Create a separate mapping for the GHCB " Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 19/36] KVM: SVM: Update the SEV-ES save area mapping Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 20/36] x86/sev: Use SEV-SNP AP creation to start secondary CPUs Brijesh Singh
2021-08-17 20:04   ` Borislav Petkov
2021-08-17 22:13     ` Tom Lendacky
2021-08-18  8:38       ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 21/36] x86/head/64: set up a startup %gs for stack protector Brijesh Singh
2021-08-19  9:34   ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 22/36] x86/sev: move MSR-based VMGEXITs for CPUID to helper Brijesh Singh
2021-08-19  9:45   ` Borislav Petkov
2021-08-19 15:37     ` Michael Roth
2021-08-19 16:46       ` Borislav Petkov
2021-08-20  3:29         ` Michael Roth
2021-08-23  4:50           ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 23/36] KVM: x86: move lookup of indexed CPUID leafs " Brijesh Singh
2021-08-19 10:07   ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 24/36] x86/compressed/acpi: move EFI config table access to common code Brijesh Singh
2021-08-19 10:47   ` Borislav Petkov
2021-08-19 14:58     ` Michael Roth
2021-08-19 17:09       ` Borislav Petkov
2021-08-19 23:42         ` Michael Roth
2021-08-23  4:52           ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 25/36] x86/boot: Add Confidential Computing type to setup_data Brijesh Singh
2021-08-19 11:06   ` Borislav Petkov
2021-07-07 18:14 ` [PATCH Part1 RFC v4 26/36] x86/compressed/64: enable SEV-SNP-validated CPUID in #VC handler Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 27/36] x86/boot: add a pointer to Confidential Computing blob in bootparams Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 28/36] x86/compressed/64: store Confidential Computing blob address " Brijesh Singh
2021-07-07 18:14 ` [PATCH Part1 RFC v4 29/36] x86/compressed/64: add identity mapping for Confidential Computing blob Brijesh Singh
2021-07-07 18:15 ` [PATCH Part1 RFC v4 30/36] x86/sev: enable SEV-SNP-validated CPUID in #VC handlers Brijesh Singh
2021-07-07 18:15 ` [PATCH Part1 RFC v4 31/36] x86/sev: Provide support for SNP guest request NAEs Brijesh Singh
2021-07-07 18:15 ` [PATCH Part1 RFC v4 32/36] x86/sev: Add snp_msg_seqno() helper Brijesh Singh
2021-07-07 18:15 ` [PATCH Part1 RFC v4 33/36] x86/sev: Register SNP guest request platform device Brijesh Singh
2021-07-07 18:15 ` [PATCH Part1 RFC v4 34/36] virt: Add SEV-SNP guest driver Brijesh Singh
2021-07-07 18:15 ` [PATCH Part1 RFC v4 35/36] virt: sevguest: Add support to derive key Brijesh Singh
2021-07-07 18:15 ` [PATCH Part1 RFC v4 36/36] virt: sevguest: Add support to get extended report Brijesh Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bd5b8826-ab0b-4f4f-8594-0c7e6232941a@amd.com \
    --to=brijesh.singh@amd.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=brijesh.ksingh@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dovmurik@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=jroedel@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=npmccallum@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pgonda@google.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=seanjc@google.com \
    --cc=slp@redhat.com \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tobin@ibm.com \
    --cc=tony.luck@intel.com \
    --cc=vbabka@suse.cz \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    --subject='Re: [PATCH Part1 RFC v4 08/36] x86/sev: check the vmpl level' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).