linux-kernel - Re: [PATCH v3 2/9] KVM: selftests: Add a basic SNP smoke test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <99e64d8e-2d10-41c7-8b7e-cd059c7e7f29@amd.com>
Date: Mon, 4 Nov 2024 14:21:04 -0600
From: "Pratik R. Sampat" <pratikrajesh.sampat@....com>
To: Sean Christopherson <seanjc@...gle.com>
CC: <kvm@...r.kernel.org>, <pbonzini@...hat.com>, <pgonda@...gle.com>,
	<thomas.lendacky@....com>, <michael.roth@....com>, <shuah@...nel.org>,
	<linux-kselftest@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/9] KVM: selftests: Add a basic SNP smoke test



On 10/31/2024 11:27 AM, Sean Christopherson wrote:
> On Thu, Oct 31, 2024, Pratik R. Sampat wrote:
>> Hi Sean,
>>
>> On 10/30/2024 12:57 PM, Sean Christopherson wrote:
>>> On Wed, Oct 30, 2024, Pratik R. Sampat wrote:
>>>> On 10/30/2024 8:46 AM, Sean Christopherson wrote:
>>>>> +/* Minimum firmware version required for the SEV-SNP support */
>>>>> +#define SNP_FW_REQ_VER_MAJOR   1
>>>>> +#define SNP_FW_REQ_VER_MINOR   51
>>>>>
>>>>> Side topic, why are these hardcoded?  And where did they come from?  If they're
>>>>> arbitrary KVM selftests values, make that super duper clear.
>>>>
>>>> Well, it's not entirely arbitrary. This was the version that SNP GA'd
>>>> with first so that kind of became the minimum required version needed.
>>>>
>>>> I think the only place we've documented this is here -
>>>> https://github.com/AMDESE/AMDSEV/tree/snp-latest?tab=readme-ov-file#upgrade-sev-firmware.
>>>>
>>>> Maybe, I can modify the comment above to say something like -
>>>> Minimum general availability release firmware required for SEV-SNP support.
>>>
>>> Hmm, so if AMD says SNP is only supported for firmware version >= 1.51, why on
>>> earth is that not checked and enforced by the kernel?  Relying on userspace to
>>> not crash the host (or worse) because of unsupported firmware is not a winning
>>> strategy.
>>
>> We do check against the firmware level 1.51 while setting things up
>> first (drivers/crypto/ccp/sev-dev.c:__sev_snp_init_locked()) and we bail
>> out if it's otherwise. From the userspace, calls to KVM_SEV_INIT2 or any
>> other corresponding SNP calls should fail cleanly without any adverse
>> effects to the host.
> 
> And I'm saying, that's not good enough.  If the platform doesn't support SNP,
> the KVM *must not* advertise support for SNP.
> 

Sure, fair to expect this. Currently, if the FW check fails, SNP is not
setup and there is nothing that indicates in the KVM capabilities (apart
from one dmesg error) that the support does not exist.

One thing I could do (as an independent patch) is to introduce a CC API
that abstracts the FW version check made by the CCP module. Since sev
platform status can be gotten before INIT to extract the major and minor
version numbers, KVM can also call into this API and use that to decide
if the KVM capabilities for SNP must be set or not.

Thanks!
Pratik

>> From the positive selftest perspective though, we want to make sure it's
>> both supported and enabled, and skip the test if not.
> 
> No, we want the test to assert that KVM reports SNP support if and only if SNP
> is 100% supported.
> 
>> I believe we can tell if it's supported by the platform using the MSR -
>> MSR_AMD64_SEV_SNP_ENABLED or the X86_FEATURE_SEV_SNP from the KVM
>> capabilities. However, to determine if it's enabled from the kernel, I
>> made this check here. Having said that, I do agree that there should
>> probably be a better way to expose this support to the userspace.
>>
>> Thanks
>> Pratik