[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170930214124.74w44yel3gijwlxj@pd.tnic>
Date: Sat, 30 Sep 2017 23:41:24 +0200
From: Borislav Petkov <bp@...e.de>
To: Brijesh Singh <brijesh.singh@....com>
Cc: Tom Lendacky <thomas.lendacky@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
kvm@...r.kernel.org, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: 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)
--
Powered by blists - more mailing lists