linux-kernel - Re: [PATCH] Perverting cciss

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] [day] [month] [year] [list]

Message-ID: <759655.87535.qm@web33012.mail.mud.yahoo.com>
Date:	Sun, 8 Apr 2007 09:26:06 -0700 (PDT)
From:	Stephen Cameron <smcameron@...oo.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	linux-kernel@...r.kernel.org, james.bottomley@...eleye.com,
	mike.miller@...com, steve.cameron@...com
Subject: Re: [PATCH] Perverting cciss

--- Christoph Hellwig <hch@...radead.org> wrote:

> Also is there a reason you don't want to pass down the various
> other ioctls scsi_cmd_ioctl can handle to it?

Didn't think about it, SG_IO is the one people were
clamoring for.

SG_GET_VERSION_NUM:
easily doable.

SCSI_IOCTL_GET_IDLUN:
Hmm, cciss is a block driver, and doesn't
really have an ID/LUN which are meaningful
in the normal sense of this ioctl.  If we
report something for this one, it is going to
conflict with some other device on the system
if that info is used in the usual way.  That is,
disk devices on cciss do not have any bus/target/lun
as far as linux is concerned, and aren't addressable
using those.

SCSI_IOCTL_GET_BUS_NUMBER:
Same problem as SCSI_IOCTL_GET_IDLUN.

SG_SET_TIMEOUT:
SG_GET_TIMEOUT:
Doable.  I don't think timeout will be honored though,
and I think this has to do with the sg driver, which
isn't involved with cciss anyhow, as cciss is not
a scsi driver (except for tape drives).

SG_GET_RESERVED_SIZE:
SG_SET_RESERVED_SIZE:
I think this is an sg driver thing and won't make
any difference for cciss, but we could pass it
through, I guess.

SG_EMULATED_HOST:

Er....  I guess we can do it:

/*
 * will always return that we are ATAPI even for a real SCSI drive, I'm not
 * so sure this is worth doing anything about (why would you care??)
 */
static int sg_emulated_host(request_queue_t *q, int __user *p)
{
        return put_user(1, p);
}

What's it for?

CDROM_SEND_PACKET:
CDROMCLOSETRAY:
CDROMEJECT:

I think all the CDROM stuff doesn't really apply.  CD-ROMs
on smartarray are not supported, nor are CD-ROMs presented
even if you attach one (excepting some weird tape device
that HP sells which sometimes pretends to be a CDROM for
booting purposes.) (Why would you put a cdrom on a RAID 
controller?)  I guess we could pass it through, it might not 
hurt, probably doesn't help though, and might give people
the mistaken impression that they can connect a SCSI cd-rom 
to a smartarray.

SCSI_IOCTL_SEND_COMMAND:

Doable, I think.

It'll be tomorrow at best before I can try anything out
or fix the other stuff you pointed out though.

-- steve

____________________________________________________________________________________
Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front
-
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/