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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 23 Sep 2021 08:59:11 +0800 From: Hao Xiang <hao.xiang@...ux.alibaba.com> To: Paolo Bonzini <pbonzini@...hat.com>, Xiaoyao Li <xiaoyao.li@...el.com>, kvm@...r.kernel.org Cc: linux-kernel@...r.kernel.org, chenyi.qiang@...el.com, shannon.zhao@...ux.alibaba.com, Sean Christopherson <seanjc@...gle.com>, hao.xiang@...ux.alibaba.com Subject: Re: [PATCH] KVM: VMX: Check if bus lock vmexit was preempted On 2021/9/22 20:40, Paolo Bonzini wrote: > On 22/09/21 12:32, Xiaoyao Li wrote: >>> >> >> EXIT_REASON.bus_lock_detected may or may not be set when exit reason >> == EXIT_REASON_BUS_LOCK. Intel will update ISE or SDM to state it. >> >> Maybe we can do below in handle_bus_lock_vmexit handler: >> >> if (!to_vmx(vcpu)->exit_reason.bus_lock_detected) >> to_vmx(vcpu)->exit_reason.bus_lock_detected = 1; >> >> But is manually changing the hardware reported value for software >> purpose a good thing? > > No. That said, Hao's patch is just making the code clearer; there's > no behavioral change since the "if" will just redo the same > assignments as handle_bus_lock_vmexit. > > Paolo I agree Paolo. EXIT_REASON.bus_lock_detected may or may not be set when exit_reason=EXIT_REASON_BUS_LOCK, It clould depend on hardware implementaion. No matter when intel states it clearly, I think it is better that we avoid repeated assignment by adding additional check condition in vmx_handle_exit. Of course , it is also ok that hand_bus_lock_vmexit do nothing , but the code is not clear, and the code logic will be inconsistent with spec description.
Powered by blists - more mailing lists