linux-kernel - Re: [PATCH] KVM: SVM: fix cr8 intercept window

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

Date:	Fri, 14 Mar 2014 10:57:32 +0100
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Radim Krčmář <rkrcmar@...hat.com>,
	Gleb Natapov <gleb@...nel.org>
CC:	Marcelo Tosatti <mtosatti@...hat.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH] KVM: SVM: fix cr8 intercept window

Il 13/03/2014 18:08, Radim Krčmář ha scritto:
> > I agree that old code is wrong and the patch looks correct, but I only
> > see how the bug may cause pending IRR to not be delivered in time,
> > not how interrupt can disrupt a higher priority task.

Right.  Also, on SMP guests the effect would likely be just a deadlock
if a lower-priority ISR interrupted a higher priority task and accessed 
shared data (since you need anyway a spinlock in addition to raising the 
IRQL).

A more likely explanation is that if the remote processor delays an IPI 
too much, it will have a stable TLB entry.  The resulting random 
corruption of paged memory is compatible with the BAD_POOL_HEADER error 
codes that Radim observed.

> Paolo, can you change the last sentence to ", which means we don't
> inject pending IRR immediately."?  (or do we just forget it?)

It's already in Linus's tree.

Paolo
--
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/