From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOJf0-0001AJ-W8 for qemu-devel@nongnu.org; Tue, 07 Jul 2009 19:01:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOJew-000193-EQ for qemu-devel@nongnu.org; Tue, 07 Jul 2009 19:01:14 -0400 Received: from [199.232.76.173] (port=41322 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOJew-000190-Bx for qemu-devel@nongnu.org; Tue, 07 Jul 2009 19:01:10 -0400 Received: from rv-out-0708.google.com ([209.85.198.246]:51861) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MOJev-0006fI-U0 for qemu-devel@nongnu.org; Tue, 07 Jul 2009 19:01:10 -0400 Received: by rv-out-0708.google.com with SMTP id b17so1411232rvf.22 for ; Tue, 07 Jul 2009 16:01:08 -0700 (PDT) Message-ID: <4A53D3B1.2020903@codemonkey.ws> Date: Tue, 07 Jul 2009 18:01:05 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/5] ATAPI pass through v2 References: <200907011931.53521.alexandre.bique@citrix.com> <20090707200327.GA3902@miranda.arrow> <5d3bb3090907071421i506a2f0bh5aca170c35a26f62@mail.gmail.com> <200907072344.33893.paul@codesourcery.com> <5d3bb3090907071550s6e832c45k804bca769aa57f70@mail.gmail.com> In-Reply-To: <5d3bb3090907071550s6e832c45k804bca769aa57f70@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexandre Bique Cc: Paul Brook , qemu-devel@nongnu.org Alexandre Bique wrote: > On Tue, Jul 7, 2009 at 10:44 PM, Paul Brook wrote: > >>>> I expect that running qemu as root counts as a 'bad idea' (I gather >>>> that commands are filtered when running as a regular user), but even so, >>>> I wonder if guests should be prevented from performing firmware updates? >>>> >>> Yeps. >>> >> I disagree. Upgrading the firmware from within the guest sounds like a >> legitimate use, especially given the proliferation of proprietary windows- >> only upgrade utilities. >> > > Maybe we could agree on a switch to forward/block this command ? > No need for a switch IMHO. If a user is doing pass through, they ought to expect that the guest has direct access to the device. The fact that we can prevent this with ATAPI is a special case. When we eventually merge in VT-d based PCI pass through, we would not be able to enforce this sort of switch. That would result in confusion on the part of users. Regards, Anthony Liguori