linux-kernel - Re: [PATCH 06/13] sg_io: whitelist a few more commands for multimedia devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Jan 2013 14:41:59 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	linux-kernel@...r.kernel.org, pmatouse@...hat.com,
	"James E.J. Bottomley" <JBottomley@...allels.com>,
	linux-scsi@...nel.org, Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH 06/13] sg_io: whitelist a few more commands for
 multimedia devices

Hello, Paolo.

On Fri, Jan 25, 2013 at 11:32:42PM +0100, Paolo Bonzini wrote:
> All you can do is use common sense, which says that if a command has
> been in a standard, someone has likely used it.  Of course someone
> _might_ have misused it too, but how likely is that?

So, that's where we differ, I guess.  When it comes to hardware
devices, especially the ones as widely and cheaply deployed as SCSI or
ATA, my common sense screams to stick to what's known to work and
don't venture outside unnecessarily.

> To try and give an answer, I grepped the "unusual" drivers in
> drivers/usb/storage.  All of them seem to use non-standard packets (i.e.
> basically are not SCSI) for their strange stuff, except two:
> initializers.c has one function that sends SCSI command 0xEC,
> realtek_cr.c uses 0xF0, both vendor specific.  So USB firmware writers,
> despite being known for tweaking SCSI standards in many ways, seem to be
> sensible in this respect.

You're grepping for known irregularities which need to be used to make
the device work.  Just read through, say, sd driver code and see how
hard it tries to stick to what's known to work rather than venturing
out to the space allowed by the spec.

The default approach in this area definitely is and should be
conservative in general.

> > I have to say that's an overly optimistic view of the world.  There
> > are even devices puking on receiving SCSI commands in a slightly
> > different sequence than windows sends them out and devices which lock
> > up if you send them enough TURs.
> 
> If it is not used, nobody will use it and setting the bit is effectively
> useless (but harmless too).

No, we don't know it's gonna be harmless.  How do we *know* that
outside of the naive expectation that devices are gonna safely and
sanely ignore things that they don't understand?

> > You would get -EPERM/ACCES whatnot from base OS and you would know the
> > command in use, no?
> 
> Yes, but I would like to avoid many iterations.  I don't have access
> myself to all that software except Windows.

I don't think it's gonna be that many iterations and would much prefer
doing several iterations and having the backing data for each command
added.

Thanks.

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