From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MhY3j-00078C-Dn for qemu-devel@nongnu.org; Sat, 29 Aug 2009 20:14:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MhY3d-00075c-P6 for qemu-devel@nongnu.org; Sat, 29 Aug 2009 20:14:14 -0400 Received: from [199.232.76.173] (port=59637 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MhY3d-00075U-MA for qemu-devel@nongnu.org; Sat, 29 Aug 2009 20:14:09 -0400 Received: from mail-yw0-f178.google.com ([209.85.211.178]:58607) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MhY3d-00053b-Cy for qemu-devel@nongnu.org; Sat, 29 Aug 2009 20:14:09 -0400 Received: by ywh8 with SMTP id 8so2968007ywh.14 for ; Sat, 29 Aug 2009 17:14:08 -0700 (PDT) Message-ID: <4A99C44E.4070906@codemonkey.ws> Date: Sat, 29 Aug 2009 19:14:06 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/7] ATAPI CDROM passthrough v5 References: <19074.63829.151234.423348@mariner.uk.xensource.com> <200908282021.45227.bique.alexandre@gmail.com> <4A9982EC.9000509@gmx.net> <4A99946F.9040307@codemonkey.ws> <4A999952.1030505@gmx.net> In-Reply-To: <4A999952.1030505@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Carl-Daniel Hailfinger Cc: Ian Jackson , qemu-devel@nongnu.org, Bique Alexandre Carl-Daniel Hailfinger wrote: > The guest can also mess up other devices with the help of specially > crafted firmware. So even if the user does not care about the effects on > a particular device, a firmware upgrade might affect other devices > (which are not used by Qemu in any way) as well. Please be more specific. How is this any different than PCI passthrough with VT-d or USB passthrough? > As a result, this is > essentially a "break out of qemu or DoS the machine under certain > conditions" feature. If that particular side effect / feature is > documented, users who read the documentation won't get any nasty surprises. > A user will get a really nasty surprise if they think they can use a flag or rely on QEMU to prevent a VM from doing something nasty with a device. If they have this feeling of security, they're likely to chmod the device to allow unprivileged users to access it. But how a device handles ATAPI commands is totally up to the device. If you issue the wrong sequence, I'm sure there are devices out there that totally hose themselves. Are you absolutely confident that every ATAPI device out there is completely safe against hostile code provided that you simply prevent the FW update commands? I'm certainly not. Regards, Anthony Liguori