qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michal Suchanek
Subject: Re: [Qemu-devel] [PATCH 0/7] ATAPI CDROM passthrough v5
Date: Tue, 19 Oct 2010 16:27:15 +0200

On 19 October 2010 08:17, Alexander Graf <address@hidden> wrote:
>
> Am 19.10.2010 um 02:10 schrieb Anthony Liguori <address@hidden>:
>
>> 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
address@hidden, 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]