linux-kernel - Re: [PATCH] xen/blkback: Check for insane amounts of request on the ring.

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]

Date:	Mon, 10 Jun 2013 12:43:19 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	david.vrabel@...rix.com, roger.pau@...rix.com,
	xen-devel <xen-devel@...ts.xen.org>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] xen/blkback: Check for insane amounts of request on the
 ring.

On Mon, Jun 10, 2013 at 04:52:35PM +0100, Jan Beulich wrote:
> >>> On 07.06.13 at 22:11, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
> > On Tue, Jun 04, 2013 at 03:57:06PM -0400, Konrad Rzeszutek Wilk wrote:
> >> +	/* N.B. 'rp', not 'rc'. */
> >> +	if (RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, rp)) {
> >> +		pr_warn(DRV_PFX "Frontend provided bogus ring requests (%d - %d = %d). 
> > Halting ring processing on dev=%04x\n",
> >> +			rp, rc, rp - rc, blkif->vbd.pdevice);
> > 
> > Hm, I seem to be able to get:
> > 
> > [  189.398095] xen-blkback:Frontend provided bogus ring requests (125 - 115 = 
> > 10). Halting ring processing on dev=800011
> > or:
> > [  478.558699] xen-blkback:Frontend provided bogus ring requests (95 - 94 = 
> > 1). Halting ring processing on dev=800011
> > 
> > Which is clearly wrong. Piggybacking on the rsp_prod_pvt does not seem to 
> > cut it.
> 
> We see that too, but not very frequently. One thing is that
> rsp_prod_pvt doesn't get printed along with rc and rp, thus
> making it not immediately obvious how this can be off in any way.
> 
> Among the instance there are cases where the printed
> difference is 32, which makes me wonder whether part of the
> problem is the >= in the macro (we may want > here).
> 
> And then we might have been living with some sort of issue in the
> past, because the existing use of the macro just causes the loop
> to be exited, with it getting re-entered subsequently (i.e. at worst
> causing performance issues).

My observation was that the rsp_prod_pvt was lagging behind b/c the 
READ requests weren't completed. In other words, the processing
of the ring was stalled b/c 'make_response' hadn't been called yet.
Which meant that rsp_prod was not updated to rsp_prod_pvt (backend
does not care about that value, only frontend does).

Going back to the rc an rp check solves the immediate 'insane ring
check'. 
--
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/