Re: [Qemu-devel] Re: [PATCH RFC] e1000: fix access 4 bytes beyond buffer end

[Gleb Natapov <gleb@redhat.com>]

On Tue, Jul 13, 2010 at 02:11:10PM +0300, Michael S. Tsirkin wrote:
> On Tue, Jul 13, 2010 at 09:35:49AM +0300, Gleb Natapov wrote:
> > On Mon, Jul 12, 2010 at 06:00:20PM -0500, Anthony Liguori wrote:
> > > On 07/12/2010 05:42 PM, Michael S. Tsirkin wrote:
> > > >On Mon, Jul 12, 2010 at 04:07:21PM -0500, Anthony Liguori wrote:
> > > >>On 07/12/2010 12:48 PM, Michael S. Tsirkin wrote:
> > > >>>We do range check for size, and get size as buffer,
> > > >>>but copy size + 4 bytes (4 is for FCS).
> > > >>>Let's copy size bytes but put size + 4 in length.
> > > >>>
> > > >>>Signed-off-by: Michael S. Tsirkin<mst@redhat.com>
> > > >>I think I'd feel slightly better if we zero'd out the FCS before
> > > >>writing it to the guest.  It is potentially a data leak.
> > > >>
> > > >>Regards,
> > > >>
> > > >>Anthony Liguori
> > > >I am guessing there's no chance guest actually looks
> > > >at this data, otherwise it won't match and we'd get errors, right?
> > > 
> > > That's my assumption too.  Although I believe there are some known
> > > issues with e1000 and certain versions of Windows and the Microsoft
> > > built-in driver.  Maybe this is why those drivers don't work and the
> > > Intel drivers do?
> > > 
> > At least one known issue with Windows drivers to me is that they
> > sometimes (on resume from S4 at least) enable interrupts before setup
> > irq routing, so if interrupt is generated in the wrong time it hangs the
> > guest. I guess it works on real HW for them because line speed
> > negotiation takes non-zero time.
> 
> I guess we could work around this. Is there a bz?
> 
BZ where? We do not support e1000 with Windows guests.

--
			Gleb.