linux-kernel - Re: [Xen-devel] [PATCH 3/3] 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, 28 Jan 2013 16:03:49 +0000
From:	David Vrabel <david.vrabel@...rix.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	David Vrabel <david.vrabel@...rix.com>,
	Konrad Rzeszutek Wilk <konrad@...nel.org>,
	<xen-devel@...ts.xensource.com>, <linux-kernel@...r.kernel.org>,
	<stable@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH 3/3] xen/blkback: Check for insane amounts
 of request on the ring.

On 28/01/13 15:44, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 28, 2013 at 11:38:50AM +0000, David Vrabel wrote:
>> On 25/01/13 18:43, Konrad Rzeszutek Wilk wrote:
>>>
>>> Check that the ring does not have an insane amount of requests
>>> (more than there could fit on the ring).
>> [...]
>>> --- a/drivers/block/xen-blkback/blkback.c
>>> +++ b/drivers/block/xen-blkback/blkback.c
>> [...]
>>> @@ -415,8 +415,12 @@ int xen_blkif_schedule(void *arg)
>>>  		blkif->waiting_reqs = 0;
>>>  		smp_mb(); /* clear flag *before* checking for work */
>>>  
>>> -		if (do_block_io_op(blkif))
>>> +		rc = do_block_io_op(blkif);
>>> +		if (rc > 0)
>>>  			blkif->waiting_reqs = 1;
>>> +		if (rc == -EACCES)
>>> +			wait_event_interruptible(blkif->shutdown_wq,
>>> +						 kthread_should_stop());
>>
>> So if this happens then the backend silently stops processing any
>> further requests?  I think it should print an error and disconnect from
>> the front end.
> 
> I was not sure what it should print?
> 
> "Frontend provided bogus ring requests. Halting ring processing"?

That would be fine but you may want to print the bad values, in case
they're useful for tracking down bugs in frontends.

> It does eventually disconnect from the front-end as the XenBus enters
> the Disconnect phase. It seemed the strike the balance - so that if
> the frontend negotiates again the ring can start again and penalize
> the frontend for giving bogus data.

Ok.

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