All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Limonciello, Mario" <mario.limonciello@amd.com>
To: Tom Lendacky <thomas.lendacky@amd.com>,
	Borislav Petkov <bp@alien8.de>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>
Cc: Kees Cook <keescook@chromium.org>,
	hughsient@gmail.com,
	Martin Fernandez <martin.fernandez@eclypsium.com>,
	linux-kernel@vger.kernel.org,
	Brijesh Singh <brijesh.singh@amd.com>
Subject: Re: [PATCH 2/2] x86/cpu: clear SME/SEV/SEV_ES features when not in use
Date: Fri, 11 Feb 2022 13:54:01 -0600	[thread overview]
Message-ID: <d705b64d-2866-e2bf-2323-dfe0cfe73da8@amd.com> (raw)
In-Reply-To: <4035f596-651c-c167-372b-ffb8ce1a0ac7@amd.com>

On 2/11/2022 08:46, Tom Lendacky wrote:
> +Brijesh (please copy him, too, on all SEV related things)
> 
> On 2/10/22 23:36, Mario Limonciello wrote:
>> Currently SME/SEV/SEV_ES features are reflective of whether the CPU
>> supports the features but not whether they have been activated by the
>> kernel.
>>
>> Change this around to clear the features if the kernel is not using
>> them so userspace can determine if they are available and in use
>> from `/proc/cpuinfo`.
>>
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>>   arch/x86/kernel/cpu/amd.c | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>> index 4edb6f0f628c..4a7d4801fa0b 100644
>> --- a/arch/x86/kernel/cpu/amd.c
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -611,12 +611,20 @@ static void early_detect_mem_encrypt(struct 
>> cpuinfo_x86 *c)
>>           if (!(msr & MSR_K7_HWCR_SMMLOCK))
>>               goto clear_sev;
>> +        if (!cc_platform_has(CC_ATTR_MEM_ENCRYPT))
>> +            goto clear_all;
>> +        if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
>> +            goto clear_sev;
>> +        if (!cc_platform_has(CC_ATTR_GUEST_STATE_ENCRYPT))
>> +            goto clear_sev_es;
>> +
> 
> A host/hypervisor will never see GUEST related attributes return true, 
> you need to verify all uses of X86_FEATURE_SEV* in the kernel. I see two 
> files where this change will break SEV hypervisor support:
> 

Maybe it's best then to just check for/clear the SME feature at this 
time and let Brijesh handle plumbing the applicable removals/additions 
for SEV/SEV_ES separately.

> - arch/x86/kvm/svm/sev.c / sev_hardware_setup()
> - drivers/crypto/ccp/sev-dev.c / sev_dev_init()
> 
> I imagine that some of this has to be re-thought a bit. The current SEV 
> and SEV-ES feature attributes are intended for hypervsior side usage.  
> For example, MSR MSR_K7_HWCR_SMMLOCK, which is likely never going to be 
> provided to a guest, needs to be checked to be certain that an SEV guest 
> can be launched, even though SEV is advertised in CPUID.
> 
> Once in the guest, it is the cc_platform_has() support that determines 
> feature support and not X86_FEATURE_SEV*
> 
> Thanks,
> Tom
> 
>>           return;
>>   clear_all:
>>           setup_clear_cpu_cap(X86_FEATURE_SME);
>>   clear_sev:
>>           setup_clear_cpu_cap(X86_FEATURE_SEV);
>> +clear_sev_es:
>>           setup_clear_cpu_cap(X86_FEATURE_SEV_ES);
>>       }
>>   }


  reply	other threads:[~2022-02-11 19:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-11  5:36 [PATCH 1/2] x86: Use CPUID 0x8000001f to confirm SME availability Mario Limonciello
2022-02-11  5:36 ` [PATCH 2/2] x86/cpu: clear SME/SEV/SEV_ES features when not in use Mario Limonciello
2022-02-11  8:31   ` Borislav Petkov
2022-02-11 19:43     ` Limonciello, Mario
2022-02-11 14:46   ` Tom Lendacky
2022-02-11 19:54     ` Limonciello, Mario [this message]
2022-02-11 20:42       ` Tom Lendacky
2022-02-11  8:28 ` [PATCH 1/2] x86: Use CPUID 0x8000001f to confirm SME availability Borislav Petkov
2022-02-11 14:55 ` Tom Lendacky
2022-02-11 19:51   ` Limonciello, Mario
2022-02-11 21:09     ` Tom Lendacky

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=d705b64d-2866-e2bf-2323-dfe0cfe73da8@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=hughsient@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.fernandez@eclypsium.com \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.