linux-kernel - Re: [RFC 3/5] selftests: KVM: SEV IOCTL 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: <f76021e4-12bb-405a-9c7e-e8ca990af34d@amd.com>
Date: Thu, 11 Jul 2024 11:23:22 -0500
From: "Sampat, Pratik Rajesh" <pratikrajesh.sampat@....com>
To: Peter Gonda <pgonda@...gle.com>
CC: <kvm@...r.kernel.org>, <shuah@...nel.org>, <thomas.lendacky@....com>,
	<michael.roth@....com>, <seanjc@...gle.com>, <pbonzini@...hat.com>,
	<linux-kselftest@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 3/5] selftests: KVM: SEV IOCTL test



On 7/11/2024 10:23 AM, Peter Gonda wrote:
>> +
>> +static void test_sev_launch(void *guest_code, uint32_t type, uint64_t policy)
>> +{
>> +       struct kvm_vcpu *vcpu;
>> +       struct kvm_vm *vm;
>> +       struct ucall uc;
>> +       bool cond;
>> +       int ret;
>> +
>> +       vm = vm_sev_create_with_one_vcpu(type, guest_code, &vcpu);
>> +       ret = sev_vm_launch_start(vm, 0);
>> +       cond = type == KVM_X86_SEV_VM ? !ret : ret;
>> +       TEST_ASSERT(cond,
>> +                   "KVM_SEV_LAUNCH_START should fail, invalid policy.");
>> +
>> +       ret = sev_vm_launch_update(vm, policy);
>> +       cond = type == KVM_X86_SEV_VM ? !ret : ret;
>> +       TEST_ASSERT(cond,
>> +                   "KVM_SEV_LAUNCH_UPDATE should fail, invalid policy.");
> 
> Isn't the reason we expect all other calls to fail here because we
> have not successfully called `sev_vm_launch_start()`?
> 

Yes you're right. The idea is that none of the consequent "good" ioctl
calls should succeed if the vm_launch_start was faulty.

>> +       sev_guest_status_assert(vm, type);
>> +
>> +       ret = sev_vm_launch_measure(vm, alloca(256));
> 
> Should we free this buffer?

Sure, I should store this into a pointer and free it.

I guess this also happens within vm_sev_launch() where we should include
a free as well.

Thanks for catching this!