linux-kernel - Re: [PATCH] KVM: SVM: Fix reserved fields of struct sev_es_save

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] [day] [month] [year] [list]

Message-ID: <1f4090b5-1522-c3c2-a1a4-b0d5cbc13da5@amd.com>
Date:   Mon, 24 Oct 2022 11:35:36 -0500
From:   Carlos Bilbao <carlos.bilbao@....com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     tglx@...utronix.de, bp@...en8.de, mingo@...hat.com,
        dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
        venu.busireddy@...cle.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>, bilbao@...edu
Subject: Re: [PATCH] KVM: SVM: Fix reserved fields of struct sev_es_save_area

On 10/22/22 02:46, Paolo Bonzini wrote:

> On 10/4/22 18:29, Sean Christopherson wrote:
>> If we really want to the number to have any kind of meaning without 
>> needing a pile
>> of churn for every update, the best idea I can think of is to name 
>> them reserved_<offset>.
>> That way only the affected reserved field needs to be modified when 
>> adding new
>> legal fields.  But that has it's own flavor of maintenance burden as 
>> calculating
>> and verifying the offset is a waste of everyone's time.
>
> Finding the right offsets is usually pretty quick because they can be 
> found in the manual (or something close to the offset can be found 
> there) and verifying them can be done with BUILD_BUG_ON.
>
> If Carlos prepared a patch using offsets (with BUILD_BUG_ON to ensure 
> no future bitrot) I would apply it gladly.  If it's just renumbering 
> as in this one, however, I'd just ignore it.
>
> Paolo
>
> Paolo
>
Sure, I'm sending that.

Thanks,

Carlos