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]

Date:   Wed, 3 Nov 2021 23:20:28 +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:
> 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>