linux-kernel - Re: [PATCH v3 2/2] KVM: Move INVPCID type check from vmx and svm to the common kvm_handle

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: <YYPm5eann2hCAryi@google.com>
Date:   Thu, 4 Nov 2021 13:57:57 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Vipin Sharma <vipinsh@...gle.com>
Cc:     pbonzini@...hat.com, jmattson@...gle.com, dmatlack@...gle.com,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] KVM: Move INVPCID type check from vmx and svm to
 the common kvm_handle_invpcid()

On Wed, Nov 03, 2021, Vipin Sharma wrote:
> On Wed, Nov 3, 2021 at 4:20 PM Sean Christopherson <seanjc@...gle.com> wrote:
> >
> > On Wed, Nov 03, 2021, Vipin Sharma wrote:
> > > Handle #GP on INVPCID due to an invalid type in the common switch
> > > statement instead of relying on the callers (VMX and SVM) to manually
> > > validate the type.
> > >
> > > Unlike INVVPID and INVEPT, INVPCID is not explicitly documented to check
> > > the type before reading the operand from memory, so deferring the
> > > type validity check until after that point is architecturally allowed.
> > >
> > > Signed-off-by: Vipin Sharma <vipinsh@...gle.com>
> > > ---
> >
> > For future reference, a R-b that comes with qualifiers can be carried so long as
> > the issues raised by the reviewer are addressed.  Obviously it can be somewhat
> > subjective, but common sense usually goes a long ways, and most reviewers won't
> > be too grumpy about mistakes so long as you had good intentions and remedy any
> > mistakes.  And if you're in doubt, you can always add a blurb in the cover letter
> > or ignored part of the patch to explicitly confirm that it was ok to add the tag,
> > e.g. "Sean, I added your Reviewed-by in patch 02 after fixing the changelog, let
> > me know if that's not what you intended".
> >
> > Thanks!
> >
> > Reviewed-by: Sean Christopherson <seanjc@...gle.com>
> 
> I was not sure if I can add R-b as it was only for the code and not
> changelog. Good to know that I can ask such things in the cover letter
> or the ignored part of the patch.

Ah, that's my bad, that was indeed a very confusing way to phrase my contingent
review.