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

Message-ID: <CAHVum0eFwgM-Pj6xHt0gkFCf1OZGjYD7K0xttswbAaGMo6zpJQ@mail.gmail.com>
Date:   Wed, 3 Nov 2021 22:17:26 -0700
From:   Vipin Sharma <vipinsh@...gle.com>
To:     Sean Christopherson <seanjc@...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 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.

Thanks
Vipin