From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Shgvi-0002fE-PQ for qemu-devel@nongnu.org; Thu, 21 Jun 2012 08:56:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Shgvc-0006M5-9n for qemu-devel@nongnu.org; Thu, 21 Jun 2012 08:56:10 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:62881) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Shgvc-0006Lb-2q for qemu-devel@nongnu.org; Thu, 21 Jun 2012 08:56:04 -0400 Received: by dadn2 with SMTP id n2so868888dad.4 for ; Thu, 21 Jun 2012 05:56:02 -0700 (PDT) Message-ID: <4FE319DE.7070809@codemonkey.ws> Date: Thu, 21 Jun 2012 07:55:58 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1340087992-2399-1-git-send-email-benh@kernel.crashing.org> <1340087992-2399-5-git-send-email-benh@kernel.crashing.org> <4FE23E30.50302@codemonkey.ws> <1340228168.28143.178.camel@pasglop> <4FE2434D.2010901@codemonkey.ws> <1340229726.28143.200.camel@pasglop> <20120621073338.GA31732@redhat.com> In-Reply-To: <20120621073338.GA31732@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 04/13] usb-ohci: Use universal DMA helper functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Gerd Hoffmann , qemu-devel@nongnu.org, David Gibson On 06/21/2012 02:33 AM, Michael S. Tsirkin wrote: > On Thu, Jun 21, 2012 at 08:02:06AM +1000, Benjamin Herrenschmidt wrote: >> On Wed, 2012-06-20 at 16:40 -0500, Anthony Liguori wrote: >> >>> Well let's return void in the DMA methods and let the IOMMUs assert on error. >>> At least that will avoid surprises until someone decides they care enough about >>> errors to touch all callers. >>> >>> I think silently failing a memcpy() can potentially lead to a vulnerability so >>> I'd rather avoid that. >> >> No I'd rather keep the error returns, really, even if that means fixing >> a few devices. I can look at making sure we don't pass random qemu data, >> on error that's reasonably easy. >> >> assert on error means guest code can assert qemu ... not a great idea >> but maybe we can add a warning. > > Why not? Guest can always just halt if it wants to anyway. > On the other hand, warnings can fill up host logs so > represent a security problem. As long as we scrub the buffers, returning an unhandled error seems okay to me. I've long thought we should have some sort of generic way to throw an error and effectively pause a single device. I'm not sure how it would work in practice though. Regards, Anthony Liguori