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

Message-ID: <d64d2144-449e-0dec-6bc1-a5478a0febc0@redhat.com>
Date:   Sat, 22 Oct 2022 09:46:04 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>,
        Carlos Bilbao <carlos.bilbao@....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/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