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: <20090316183000.GC3783@amt.cnet>
Date:	Mon, 16 Mar 2009 15:30:00 -0300
From:	Marcelo Tosatti <mtosatti@...hat.com>
To:	Avi Kivity <avi@...hat.com>
Cc:	Joerg Roedel <joerg.roedel@....com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kvm/x86: check KVM_REQ_TLB_FLUSH with irqs disabled

On Mon, Mar 16, 2009 at 03:12:52PM +0200, Avi Kivity wrote:
> Joerg Roedel wrote:
>> For KVM remote TLB flushes we need to check the KVM_REQ_TLB_FLUSH
>> request flag when the irqs are already disabled. Otherwise there is a
>> small window of time for a race condition where we may enter a guest
>> without doing a requested TLB flush.
>>
>> @@ -3108,8 +3108,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
>>  			kvm_write_guest_time(vcpu);
>>  		if (test_and_clear_bit(KVM_REQ_MMU_SYNC, &vcpu->requests))
>>  			kvm_mmu_sync_roots(vcpu);
>> -		if (test_and_clear_bit(KVM_REQ_TLB_FLUSH, &vcpu->requests))
>> -			kvm_x86_ops->tlb_flush(vcpu);
>>  		if (test_and_clear_bit(KVM_REQ_REPORT_TPR_ACCESS,
>>  				       &vcpu->requests)) {
>>  			kvm_run->exit_reason = KVM_EXIT_TPR_ACCESS;
>> @@ -3133,6 +3131,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
>>   	local_irq_disable();
>>  +	if (test_and_clear_bit(KVM_REQ_TLB_FLUSH, &vcpu->requests))
>> +		kvm_x86_ops->tlb_flush(vcpu);
>> +
>>  	if (vcpu->requests || need_resched() || signal_pending(current)) {
>>  		local_irq_enable();
>>  		preempt_enable();
>>   
>
> If we lost the race and someone sets a bit after the test, then the test  
> immediately above will pick this up retry the bit tests.

BTW, I've wondered if the local_irq_enable in svm_vcpu_run is safe:

        clgi();

        local_irq_enable();

There is no way that an interrupt can be handled there without an exit, 
right?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ