From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFmdX-0000YT-Ii for qemu-devel@nongnu.org; Mon, 17 Oct 2011 08:49:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFmdR-0003IW-MG for qemu-devel@nongnu.org; Mon, 17 Oct 2011 08:49:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFmdR-0003IC-FE for qemu-devel@nongnu.org; Mon, 17 Oct 2011 08:49:41 -0400 Date: Mon, 17 Oct 2011 14:50:43 +0200 From: "Michael S. Tsirkin" Message-ID: <20111017125031.GJ4537@redhat.com> References: <57386830befff359aa6eac1610816eb9c853a05d.1318843693.git.jan.kiszka@siemens.com> <20111017111045.GB4537@redhat.com> <4E9C1042.4040007@siemens.com> <20111017115721.GF4537@redhat.com> <4E9C1A6E.1010404@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9C1A6E.1010404@siemens.com> Subject: Re: [Qemu-devel] [RFC][PATCH 06/45] msix: Prevent bogus mask updates on MMIO accesses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Alex Williamson , Marcelo Tosatti , Avi Kivity , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" On Mon, Oct 17, 2011 at 02:07:10PM +0200, Jan Kiszka wrote: > On 2011-10-17 13:57, Michael S. Tsirkin wrote: > > On Mon, Oct 17, 2011 at 01:23:46PM +0200, Jan Kiszka wrote: > >> On 2011-10-17 13:10, Michael S. Tsirkin wrote: > >>> On Mon, Oct 17, 2011 at 11:27:40AM +0200, Jan Kiszka wrote: > >>>> Only accesses to the MSI-X table must trigger a call to > >>>> msix_handle_mask_update or a notifier invocation. > >>>> > >>>> Signed-off-by: Jan Kiszka > >>> > >>> Why would msix_mmio_write be called on an access > >>> outside the table? > >> > >> Because it handles both the table and the PBA. > > > > Hmm. Interesting. Is there a bug in how we handle PBA > > updates then? If yes I'd like a separate patch for that > > to apply to the stable tree. > > I first thought it was a serious bug, but it just triggers if the guest > write to PBA (which is very uncommon) and that actually triggers any > spurious out-of-bounds vector injection. Highly unlikely. Yes guests don't really use PBA ATM. But is there something bad a malicious guest can do? For example, what if msix_clr_pending gets invoked with this huge vector value? It does seem serious ... > > > > BTW, this code will go away if PBA can get stored separately? > > Hmm - yeah, true. Likely it's moot to discuss this change then. > > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux