Re: [Qemu-devel] [PATCH 0/7] ATAPI CDROM passthrough v5

2010-10-19 Thread Alexander Graf

Am 19.10.2010 um 02:10 schrieb Anthony Liguori anth...@codemonkey.ws:

 On 10/18/2010 06:29 PM, Alexander Graf wrote:
 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.
 
 Ping?
   
 
 Who are you pinging?

Mostly Ian. I haven't seen any follow-up on this discussion and would like to 
know why and if there's still plans to upstream this code :).

Alex

 



Re: [Qemu-devel] [PATCH 0/7] ATAPI CDROM passthrough v5

2010-10-19 Thread Michal Suchanek
On 19 October 2010 08:17, Alexander Graf ag...@suse.de wrote:

 Am 19.10.2010 um 02:10 schrieb Anthony Liguori anth...@codemonkey.ws:

 On 10/18/2010 06:29 PM, Alexander Graf wrote:
 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.

 Ping?


 Who are you pinging?

 Mostly Ian. I haven't seen any follow-up on this discussion and would like to 
 know why and if there's still plans to upstream this code :).


Why is allowing ATAPI passthrough such a problem?

Sure if your boot drive is on the same IDE cable as the device you may
have issues but other than that the device may just stop working if it
is not designed to handle incorrect command gracefully (ie it is
broken).

I am sure there are devices that also break under issuing correct
commands or commands that look vaguely sane. Eg. there are CD-ROMs
that would lock up the whole system when you boot certain vintage of
Linux (not tested with current Linux due to lack of old hardware) on a
machine with the Intel BX chipset and one of these CD-ROMs attached
over IDE cable.

However, assuming random hardware breakage you cannot allow anything.

Perhaps the ATAPI passthrough should be designed to allow any commands
and some command profiles could be selected to allow for some
sane/conservative subset, burning, LightScribe, LabelFlash, disc
t...@tto, FW upgrade, ..

It would be nice if these subsets were defined in a configuration file
so that people can create their own 'default' combination or just
install a new set when a new fancy feature comes out.

Thanks

Michal



Re: [Qemu-devel] [PATCH 0/7] ATAPI CDROM passthrough v5

2010-10-18 Thread Alexander Graf

On 30.08.2009, at 02:14, Anthony Liguori wrote:

 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.

Ping?


Alex




Re: [Qemu-devel] [PATCH 0/7] ATAPI CDROM passthrough v5

2010-10-18 Thread Anthony Liguori

On 10/18/2010 06:29 PM, Alexander Graf wrote:

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.
 

Ping?
   


Who are you pinging?

Regards,

Anthony Liguori


Alex