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
| ||
|
Date: Tue, 2 Nov 2021 19:19:26 +0000 From: Sean Christopherson <seanjc@...gle.com> To: Vipin Sharma <vipinsh@...gle.com> Cc: Jim Mattson <jmattson@...gle.com>, pbonzini@...hat.com, dmatlack@...gle.com, kvm@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] KVM: VMX: Add a wrapper for reading INVPCID/INVEPT/INVVPID type On Tue, Nov 02, 2021, Vipin Sharma wrote: > Sorry for the late reply. > > On Thu, Oct 14, 2021 at 10:05 AM Jim Mattson <jmattson@...gle.com> wrote: > > > > On Thu, Oct 14, 2021 at 9:54 AM Sean Christopherson <seanjc@...gle.com> wrote: > > > Oh, yeah, definitely. I missed that SVM's invpcid_interception() has the same > > > open-coded check. > > > > > > Alternatively, could we handle the invalid type in the main switch statement? I > > > don't see anything in the SDM or APM that architecturally _requires_ the type be > > > checked before reading the INVPCID descriptor. Hardware may operate that way, > > > but that's uArch specific behavior unless there's explicit documentation. > > > > Right. INVVPID and INVEPT are explicitly documented to check the type > > first, but INVPCID is not. > > It seems to me that I can move type > 3 check to kvm_handle_invpcid() > switch statement. I can replace BUG() in that switch statement with > kvm_inject_gp for the default case, I won't even need INVPCID_TYPE_MAX > in this case. Yep. > If you are fine with this approach then I will send out a patch where > invalid type is handled in kvm_handle_invpcid() switch statement. This has my vote.
Powered by blists - more mailing lists