Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1741312 > unrolled thread

Re: [Part1 PATCH v5 02/17] x86/mm: Add Secure Encrypted Virtualization (SEV) support

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Part1 PATCH v5 02/17] x86/mm: Add Secure Encrypted  Virtualization (SEV) support Borislav Petkov <bp@suse.de> - 2017-09-28 11:10 +0200
    Re: [Part1 PATCH v5 02/17] x86/mm: Add Secure Encrypted  Virtualization (SEV) support Borislav Petkov <bp@suse.de> - 2017-09-28 21:30 +0200
      Re: [Part1 PATCH v5 02/17] x86/mm: Add Secure Encrypted  Virtualization (SEV) support Borislav Petkov <bp@suse.de> - 2017-09-29 16:50 +0200
        Re: [Part1 PATCH v5 02/17] x86/mm: Add Secure Encrypted  Virtualization (SEV) support Borislav Petkov <bp@suse.de> - 2017-09-29 18:00 +0200
    Re: [Part1 PATCH v5.1 02/17] x86/mm: Add Secure Encrypted  Virtualization (SEV) support Borislav Petkov <bp@suse.de> - 2017-09-30 11:00 +0200
    [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option Borislav Petkov <bp@suse.de> - 2017-09-30 14:00 +0200
      Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option Borislav Petkov <bp@suse.de> - 2017-09-30 23:50 +0200
        Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option Borislav Petkov <bp@suse.de> - 2017-10-01 19:20 +0200
          Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option Borislav Petkov <bp@suse.de> - 2017-10-02 00:10 +0200
            Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option Borislav Petkov <bp@suse.de> - 2017-10-02 14:50 +0200

#1741312 — Re: [Part1 PATCH v5 02/17] x86/mm: Add Secure Encrypted Virtualization (SEV) support

On Wed, Sep 27, 2017 at 10:13:14AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
> 
> Provide support for Secure Encrypted Virtualization (SEV). This initial
> support defines a flag that is used by the kernel to determine if it is
> running with SEV active.
> 
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: linux-kernel@vger.kernel.org
> Cc: x86@kernel.org
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
>  arch/x86/include/asm/mem_encrypt.h |  6 ++++++
>  arch/x86/mm/mem_encrypt.c          | 26 ++++++++++++++++++++++++++
>  include/linux/mem_encrypt.h        |  7 +++++--
>  3 files changed, 37 insertions(+), 2 deletions(-)

Reviewed-by: Borislav Petkov <bp@suse.de>

> +bool sev_active(void)
> +{
> +	return sme_me_mask && sev_enabled;

What I'm still missing is the chicken bit. I.e., to be able to boot with
"mem_encrypt=smeonly" or so, which disables the SEV side but can still
allow SME. For when SEV has issues and people want to disable it.

You can do the patch ontop of those and send it as a reply to this
thread - no need to wait to resend the whole thing again.

Thanks.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [next] | [standalone]

#1741790

Hi,

On Thu, Sep 28, 2017 at 01:48:48PM -0500, Brijesh Singh wrote:
> Let me understand the ask, are you saying that we need a method to disable the SEV
> feature from the host OS so that Hypervisor will not be able to create a SEV guest?
> Because once a guest is booted with SEV feature, there is no way to disable the SEV
> feature from the guest.
> 
> i.e if "mem_encrypt=smeonly" is set then we clear X86_FEATURE_SEV capability flag
> defined in [1].

So actually we need chicken bits to be able to *enable* both when
CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT is not set.

I.e.,

* mem_encrypt=on - both SME and SEV enabled

* mem_encrypt=smeonly - only SME, no SEV on the host. This option will
basically prevent from using any SEV guests and make the SEV part of the
code inactive. I.e., sev_active() and sev_enabled should be false. As
you say above, we should clear X86_FEATURE_SEV, yes.

* mem_encrypt=off - neither SME/SEV are enabled.

And =on and =off we already have.

How does that sound?

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1742169

On Fri, Sep 29, 2017 at 07:28:47AM -0500, Brijesh Singh wrote:
> if we are adding a chicken bits then I think we should do it for both
> "smeonly" and "sevonly". We can boot host OS with SME disabled and SEV
> enabled, and still be able to create the SEV guest from the hypervisor.

Sure, but is that a real use case? I mean, who would want to run
encrypted guests on an unencrypted hypervisor?

> How about this ?
> 
> mem_encrypt=on     both SME and SEV enabled
> mem_encrypt=sev    only SEV enabled
> mem_encrypt=sme   only SME enabled
> mem_encrypt=off     neither SME/SEV are enabled

I like those short mnemonics, ACK. Less typing is always good.

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1742216

On Fri, Sep 29, 2017 at 10:54:39AM -0500, Brijesh Singh wrote:
> In production, you do not want to run encrypted guest on an unencrypted
> hypervisor -- I was thinking about the debug environment. We can start
> with mem_encrypt=sme and if we see the need for 'sev' arg then we can
> extend it later.

Yap, exactly.

> I am working on the patch and will send for the review. thanks

Thanks.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1742568 — Re: [Part1 PATCH v5.1 02/17] x86/mm: Add Secure Encrypted Virtualization (SEV) support

On Fri, Sep 29, 2017 at 04:27:47PM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
> 
> Provide support for Secure Encrypted Virtualization (SEV). This initial
> support defines a flag that is used by the kernel to determine if it is
> running with SEV active.
> 
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: linux-kernel@vger.kernel.org
> Cc: x86@kernel.org
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---
> 
> Hi Boris,
> 
> Similar to the sme_me_mask, sev_enabled must live in .data section otherwise it
> will get zero'ed in clear_bss() and we will loose the value. I have encountered
> this issue when booting SEV guest using qemu's -kernel option.

Ah, good catch.

> I have removed your R-b since was not sure if you are still okay with the change.

Sure, looks good still.

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1742622 — [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On Fri, Sep 29, 2017 at 06:06:52PM -0500, Brijesh Singh wrote:
> The mem_encrypt=on activates both SME and SEV. Add a new argument to disable
> the SEV and allow SME. The argument can be useful when SEV has issues and
> we want to disable it.
> 
> early_detect_mem_encrypt() [cpu/amd.com] will need to know the state of
> the mem_encrypt= argument. Since early_detect_mem_encrypt() is not defined
> as __init hence we are not able to use the 'boot_command_line' variable to
> parse the cmdline argument. We introduce a new function me_cmdline_state()
> to get the cmdline state from mem_encrypt.c.
> 
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Radim Krčmář" <rkrcmar@redhat.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: kvm@vger.kernel.org
> Cc: x86@kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> ---

Ok, I went and simplified this whole code path a bit because it was
needlessly a bit too complex. Below is the result, only compile-tested.

Brijesh, Tom, guys, please check my logic, I might've missed a case.

Thanks.

---
From: Borislav Petkov <bp@suse.de>
Date: Sat, 30 Sep 2017 13:33:26 +0200
Subject: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

Extend the mem_encrypt= cmdline option with the "sme" argument so that
one can enable SME only (i.e., this serves as a SEV chicken bit). While
at it, streamline and document the flow logic here:

1. Check whether the SME CPUID leaf is present

2. Check whether the HW has enabled SME/SEV

3. Only *then* look at any potential command line params because doing
so before is pointless.

3.1 mem_encrypt=on  - enable both SME/SEV
3.2 mem_encrypt=sme - enable only SME
3.3 mem_encrypt=off - disable both

In addition, CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT enables both if
the kernel is built with it enabled.

While at it, shorten variable names, simplify code flow.

This is based on a patch by Brijesh Singh <brijesh.singh@amd.com>.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: kvm@vger.kernel.org
Cc: x86@kernel.org
---
 arch/x86/include/asm/mem_encrypt.h |  2 +
 arch/x86/kernel/cpu/amd.c          |  6 +++
 arch/x86/mm/mem_encrypt.c          | 82 +++++++++++++++++++-------------------
 3 files changed, 49 insertions(+), 41 deletions(-)

diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h
index 3ba68c92be1b..175310f00202 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -19,6 +19,8 @@
 
 #include <asm/bootparam.h>
 
+extern bool sev_enabled;
+
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 
 extern u64 sme_me_mask;
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index c1234aa0550c..d0669f3966a6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -13,6 +13,7 @@
 #include <asm/smp.h>
 #include <asm/pci-direct.h>
 #include <asm/delay.h>
+#include <asm/mem_encrypt.h>
 
 #ifdef CONFIG_X86_64
 # include <asm/mmconfig.h>
@@ -32,6 +33,8 @@ static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum);
  */
 static u32 nodes_per_socket = 1;
 
+bool sev_enabled __section(.data) = false;
+
 static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
 {
 	u32 gprs[8] = { 0 };
@@ -588,6 +591,9 @@ static void early_detect_mem_encrypt(struct cpuinfo_x86 *c)
 		if (IS_ENABLED(CONFIG_X86_32))
 			goto clear_all;
 
+		if (!sev_enabled)
+			goto clear_sev;
+
 		rdmsrl(MSR_K7_HWCR, msr);
 		if (!(msr & MSR_K7_HWCR_SMMLOCK))
 			goto clear_sev;
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 057417a3d9b4..9b83bc1be7c0 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -27,12 +27,14 @@
 #include <asm/processor-flags.h>
 #include <asm/msr.h>
 #include <asm/cmdline.h>
+#include <asm/mem_encrypt.h>
 
 #include "mm_internal.h"
 
-static char sme_cmdline_arg[] __initdata = "mem_encrypt";
-static char sme_cmdline_on[]  __initdata = "on";
-static char sme_cmdline_off[] __initdata = "off";
+static char sme_cmd[] __initdata = "mem_encrypt";
+static char sme_cmd_on[]  __initdata = "on";
+static char sme_cmd_off[] __initdata = "off";
+static char sme_cmd_sme[] __initdata = "sme";
 
 /*
  * Since SME related variables are set early in the boot process they must
@@ -44,8 +46,6 @@ EXPORT_SYMBOL_GPL(sme_me_mask);
 DEFINE_STATIC_KEY_FALSE(__sev);
 EXPORT_SYMBOL_GPL(__sev);
 
-static bool sev_enabled __section(.data) = false;
-
 /* Buffer used for early in-place encryption by BSP, no locking needed */
 static char sme_early_buffer[PAGE_SIZE] __aligned(PAGE_SIZE);
 
@@ -768,13 +768,13 @@ void __init sme_encrypt_kernel(void)
 
 void __init __nostackprotector sme_enable(struct boot_params *bp)
 {
-	const char *cmdline_ptr, *cmdline_arg, *cmdline_on, *cmdline_off;
+	const char *cmdline_ptr, *cmd, *cmd_on, *cmd_off, *cmd_sme;
 	unsigned int eax, ebx, ecx, edx;
 	unsigned long feature_mask;
-	bool active_by_default;
-	unsigned long me_mask;
+	u64 me_mask, msr;
 	char buffer[16];
-	u64 msr;
+	bool sme_only;
+	int ret;
 
 	/* Check for the SME/SEV support leaf */
 	eax = 0x80000000;
@@ -808,55 +808,55 @@ void __init __nostackprotector sme_enable(struct boot_params *bp)
 	if (!(eax & feature_mask))
 		return;
 
-	me_mask = 1UL << (ebx & 0x3f);
-
-	/* Check if memory encryption is enabled */
+	/* For SME, check the SYSCFG MSR */
 	if (feature_mask == AMD_SME_BIT) {
-		/* For SME, check the SYSCFG MSR */
 		msr = __rdmsr(MSR_K8_SYSCFG);
 		if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
 			return;
-	} else {
-		/* For SEV, check the SEV MSR */
+	}
+
+	/* For SEV, check the SEV MSR */
+	if (feature_mask == AMD_SEV_BIT) {
 		msr = __rdmsr(MSR_AMD64_SEV);
 		if (!(msr & MSR_AMD64_SEV_ENABLED))
 			return;
-
-		/* SEV state cannot be controlled by a command line option */
-		sme_me_mask = me_mask;
-		sev_enabled = true;
-		return;
 	}
 
+	me_mask = BIT_ULL(ebx & 0x3f);
+
 	/*
 	 * Fixups have not been applied to phys_base yet and we're running
 	 * identity mapped, so we must obtain the address to the SME command
 	 * line argument data using rip-relative addressing.
 	 */
-	asm ("lea sme_cmdline_arg(%%rip), %0"
-	     : "=r" (cmdline_arg)
-	     : "p" (sme_cmdline_arg));
-	asm ("lea sme_cmdline_on(%%rip), %0"
-	     : "=r" (cmdline_on)
-	     : "p" (sme_cmdline_on));
-	asm ("lea sme_cmdline_off(%%rip), %0"
-	     : "=r" (cmdline_off)
-	     : "p" (sme_cmdline_off));
-
-	if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT))
-		active_by_default = true;
-	else
-		active_by_default = false;
+	asm ("lea sme_cmd(%%rip), %0"	  : "=r" (cmd)	   : "p" (sme_cmd));
+	asm ("lea sme_cmd_on(%%rip), %0"  : "=r" (cmd_on)  : "p" (sme_cmd_on));
+	asm ("lea sme_cmd_off(%%rip), %0" : "=r" (cmd_off) : "p" (sme_cmd_off));
+	asm ("lea sme_cmd_sme(%%rip), %0" : "=r" (cmd_sme) : "p" (sme_cmd_sme));
 
 	cmdline_ptr = (const char *)((u64)bp->hdr.cmd_line_ptr |
-				     ((u64)bp->ext_cmd_line_ptr << 32));
+				    ((u64)bp->ext_cmd_line_ptr << 32));
 
-	cmdline_find_option(cmdline_ptr, cmdline_arg, buffer, sizeof(buffer));
+	ret = cmdline_find_option(cmdline_ptr, cmd, buffer, sizeof(buffer));
+	if (ret < 0)
+		return;
 
-	if (!strncmp(buffer, cmdline_on, sizeof(buffer)))
-		sme_me_mask = me_mask;
-	else if (!strncmp(buffer, cmdline_off, sizeof(buffer)))
+	if (!strncmp(buffer, cmd_off, sizeof(buffer))) {
 		sme_me_mask = 0;
-	else
-		sme_me_mask = active_by_default ? me_mask : 0;
+		return;
+	} else if (!strncmp(buffer, cmd_on, sizeof(buffer))) {
+		sme_me_mask = me_mask;
+	} else if (!strncmp(buffer, cmd_sme, sizeof(buffer))) {
+		sme_only = true;
+	}
+
+	if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT))
+		sme_me_mask = me_mask;
+
+	if (sme_only)
+		return;
+
+	/* For SEV, check the SEV MSR */
+	if (feature_mask == AMD_SEV_BIT)
+		sev_enabled = true;
 }
-- 
2.13.0

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1742700 — Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On Sat, Sep 30, 2017 at 04:17:39PM -0500, Brijesh Singh wrote:
> I will take a closure look at this patch on Monday but at a glance I am
> not sure if patch is addressing our main issue. We were trying to limit
> the SEV feature exposure from the host OS. The current logic is:
> 
> 1. Check whether the SME CPUID leaf is present

Check.

> 2. Check if we are running under hypervisor

Check.

> 3. If we are running under hypervisor, check SME_ENABLED bit in
> MSR_AMD64_SEV

Check.

> 3.1 If bit is cleared, its non SEV guest. Return from the function.

Check.

> 3.2 If bit is set, its SEV guest. We set sev_enabled to 'true' and also
> set 'sme_me_mask'. Return from the function.
> The SEV state *cannot* be controlled by a command line option.

So how do you propose to disable SEV? Right now I do:

        if (feature_mask == AMD_SEV_BIT)
                sev_enabled = true;

at the end, when mem_encrypt=sme wasn't supplied on the cmdline. IOW,
SEV is enabled either when CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT or
mem_encrypt=on.

Hmmm?

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1742852 — Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On Sun, Oct 01, 2017 at 12:00:31PM -0500, Brijesh Singh wrote:
> When SEV feature is disabled, KVM will not be able to launch any SEV
> guests.  When SEV support is available, KVM can enable it in a specific
> VM by setting SEV bit before executing the VMRUN instruction.

So I want to be able to disable SEV and the whole code that comes with
it in the *host*.

> Guest OS:
> --------
> Checks the MSR_AMD64_SEV to determine if SEV feature is enabled. Please
> note that the MSR is a read-only. IOW, MSR is not intercepted by the
> hypervisor.
> 
> Currently, mem_encrypt=xxx and CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
> is don't care. We can not depend on the command line because when SEV is
> enabled in a VM then instruction fetch will be decrypted by the
> hardware. If we want then we can perform the comparison between the SEV
> state obtained through MSR with user supplied command line and trigger
> BUG() if they don't match.

And when we have supplied mem_encrypt=sme to the *host* cmdline, it
should be impossible to start SEV guests. IOW, that feature mask test
should not happen and I should do instead:

        } else if (!strncmp(buffer, cmd_sme, sizeof(buffer))) {
                sme_only = true;
		sev_enabled = false;
        }

Or, respectively, not set it here as it is false already but set it at
the end of the function like this:

        if (sme_only)
                return;

	sev_enabled = true;
}

Hmmm?

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1742894 — Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On Sun, Oct 01, 2017 at 02:45:09PM -0500, Brijesh Singh wrote:
> >
> > So I want to be able to disable SEV and the whole code that comes with
> > it in the *host*.
> 
> We can add a new variable 'sme_only'. By default this variable should be set
> to false. When mem_encrypt=sme is passed then set it to true and
> based on sme_only state early_detect_mem_encrypt() can clear X86_FEATURE_SEV
> flag.

Why would you need yet another variable? We have sev_enabled already?!?

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1743189 — Re: [PATCH] x86/CPU/AMD, mm: Extend with mem_encrypt=sme option

On Mon, Oct 02, 2017 at 06:32:18AM -0500, Brijesh Singh wrote:
> Because sev_enabled will always be 'false' when we are booting on bare
> metal. Whereas when we are running under hypervisor then this variable
> will be true for the SEV guest, please see [1].

Ok, then. This needs absolutely to be documented. Please add a comment
over sev_enabled's definition.

> Both sev_active() and sme_active() make use of this variable
> hence we will not be able to set the sev_enabled variable on bare
> metal. Basically none of the SEV cases will be executed on bare
> metal -- only thing which we need to take care of is clearing the
> X86_FEATURE_SEV flag so that hypervisor will never launch SEV guest
> when mem_encrypt=sme option is provided.

In that case, you want to disable SEV at the guest loading point,
i.e., sev_guest_init() AFAICT is the earliest time we start prepping
a SEV guest. You can add a __setup() early param which parses
"mem_encrypt=sme", to arch/x86/kernel/cpu/amd.c and which sets a
sev_host_enabled bool or so. sev_guest_init() can then check that
variable before going any further. No need for any of that early parsing
changes.

I'll send a patch with the rest of my cleanups ontop of yours later.

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web