linux-kernel - Re: [PATCH v2 8/8] KVM: SVM: Allocate SEV command structures on local stack

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: <24cd7d2b-3b74-6b51-aa9a-554003fe5cec@csgroup.eu>
Date:   Wed, 7 Apr 2021 19:06:35 +0200
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Sean Christopherson <seanjc@...gle.com>,
        Borislav Petkov <bp@...e.de>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Brijesh Singh <brijesh.singh@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        John Allen <john.allen@....com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 8/8] KVM: SVM: Allocate SEV command structures on local
 stack



Le 07/04/2021 à 19:05, Sean Christopherson a écrit :
> On Wed, Apr 07, 2021, Borislav Petkov wrote:
>> First of all, I'd strongly suggest you trim your emails when you reply -
>> that would be much appreciated.
>>
>> On Wed, Apr 07, 2021 at 07:24:54AM +0200, Christophe Leroy wrote:
>>>> @@ -258,7 +240,7 @@ static int sev_issue_cmd(struct kvm *kvm, int id, void *data, int *error)
>>>>    static int sev_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp)
>>>>    {
>>>>    	struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info;
>>>> -	struct sev_data_launch_start *start;
>>>> +	struct sev_data_launch_start start;
>>>
>>> struct sev_data_launch_start start = {0, 0, 0, 0, 0, 0, 0};
>>
>> I don't know how this is any better than using memset...
>>
>> Also, you can do
>>
>> 	... start = { };
>>
>> which is certainly the only other alternative to memset, AFAIK.
>>
>> But whatever you do, you need to look at the resulting asm the compiler
>> generates. So let's do that:
> 
> I'm ok with Boris' version, I'm not a fan of having to count zeros.  I used
> memset() to defer initialization until after the various sanity checks, and
> out of habit.
> 

Yes I also like Boris' version 	... start = { };  better than mine.