lkml.org 
[lkml]   [2004]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: ide-cd problems
Date
From

On Tue, 03 Aug 2004 00:54:31 BST, Alan Cox wrote:
>On Sad, 2004-07-31 at 21:00, Jens Axboe wrote:
>> If you want it to work that way, you have the have a pass-through filter
>> in the kernel knowing what commands are out there (including vendor
>> specific ones). That's just too ugly and not really doable or
>> maintainable, sorry.
>
>I disagree providing you turn it the other way around. The majority of
>scsi commands have to be protected because you can destroy the drive
>with some of them or bypass the I/O layers. (Eg using SG_IO to do writes
>to raw disk to bypass auditing layers)
>

Where would the case of firmware download fit? For x86 ATA/ATAPI
devices, the vendor usually supplies a dos disk to accomplish this.
However, that method is absolutely broken a PPC system. We have to
use a proprietary driver that was written using vendor specific
commands. I assume that all vendors have their own set of
proprietary commands, specific to the device to be updated.

Usually one does not need to do firmware updates, but when
necessary, it is generally a requirement to do it on the system with
the device, not to remove the device and carry it to a system where
it can be done.

If there was an interface to allow wide open operations, including a
non-interrupt (polling) mode of operation, this would cover a large
portion of devices.

>So you need CAP_SYS_RAWIO for most commands. You can easily build a list
>of sane commands for a given media type that are harmless and it fits
>the kernel role of a gatekeeper to do that.

>
>Providing the 'allowed' function is driver level and we also honour
>read/write properly for that case (so it doesnt bypass block I/O
>restrictions and fail the least suprise test) then it seems quite
>doable.
>
>For such I/O you'd then do
>
> if(capable(CAP_SYS_RAWIO) || driver->allowed(driver, blah, cmdblock))
>
>If the allowed function filters positively "unknown is not allowed" and
>the default allowed function is simply "no" it works.
>
>We'd end up with a list of allowed commands for all sorts of operations
>that don't threaten the machine while blocking vendor specific wonders
>and also cases where users can do stuff like firmware erase.

Allowed commands are really on a device specfic basis. And a RAS
requirement, for at least those of use that have funny endianess
hardware. :)

++doug


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.104 / U:13.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site