linux-kernel - Re: [PATCH v3 0/9] SEV Kernel Selftests

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: <87115c3a-4e8b-4cad-901a-07c7f4f77ac9@amd.com>
Date: Mon, 21 Oct 2024 15:23:55 -0500
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 0/9] SEV Kernel Selftests

Hi Sean,

On 10/14/2024 5:23 PM, Sean Christopherson wrote:
> On Thu, Sep 05, 2024, Pratik R. Sampat wrote:
>> This series primarily introduces SEV-SNP test for the kernel selftest
>> framework. It tests boot, ioctl, pre fault, and fallocate in various
>> combinations to exercise both positive and negative launch flow paths.
>>
>> Patch 1 - Adds a wrapper for the ioctl calls that decouple ioctl and
>> asserts, which enables the use of negative test cases. No functional
>> change intended.
>> Patch 2 - Extend the sev smoke tests to use the SNP specific ioctl
>> calls and sets up memory to boot a SNP guest VM
>> Patch 3 - Adds SNP to shutdown testing
>> Patch 4, 5 - Tests the ioctl path for SEV, SEV-ES and SNP
>> Patch 6 - Adds support for SNP in KVM_SEV_INIT2 tests
>> Patch 7,8,9 - Enable Prefault tests for SEV, SEV-ES and SNP
> 
> There are three separate series here:
> 
>  1. Smoke test support for SNP
>  2. Negative tests for SEV+
>  3. Prefault tests for SEV+
> 
> #3 likely has a dependency on #1, and probably on #2 as well (for style if nothing
> else).  But that's really just an argument for focuing on #1 first, and the moving
> onto the others once that's ready to go.

Based on your feedback on the rest of this patchset, this makes sense to
me. I will first prep for the changes for patchset #1 and once we lock
that down I can introduce patchset #2 and #3 based on that design.

Thank you again for your feedback!
Pratik