linux-kernel - REQUEST_SENSE and ide-cd.c

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

Message-ID: <46949541.4040206@itg.hitachi.co.jp>
Date:	Wed, 11 Jul 2007 17:30:57 +0900
From:	Piotr Muszynski <piotr@....hitachi.co.jp>
To:	linux-kernel@...r.kernel.org
Subject: REQUEST_SENSE and ide-cd.c

I am adding transparent ATAPI capability to USB gadget Mass Storage 
driver. The idea is to pass USB traffic to block device queue as packet 
requests. At the end of the queue, the requests are handled by ide-cd.c 
driver.

It breaks when the ide-cd.c driver unconditionally generates 
REQUEST_SENSE for requests that ended in unit attention condition.

By clearing the drive's unit attention condition, this additional 
REQUEST_SENSE confuses the host, which fires it's own REQUEST_SENSE 
packet, to which the drive replies with NO SENSE.

I can see three solutions:

1. Intercept the sense data returned by ide-cd.c and emulate unit 
attention condition in file_storage.c driver;

2. Introduce a new request flag causing ide-cd.c to skip calling 
cdrom_queue_request_sense() for flagged requests, like below:

     cdrom_decode_status() 2.6.12:
     -    if (stat & ERR_STAT) {
     +    if (stat & ERR_STAT && !(rq->flags & REQ_NO_AUTOSENSE)) {
              spin_lock_irqsave(&ide_lock, flags);
              blkdev_dequeue_request(rq);
              HWGROUP(drive)->rq = NULL;
              spin_unlock_irqrestore(&ide_lock, flags);
              cdrom_queue_request_sense(drive, rq->sense, rq);
          } else
              cdrom_end_request(drive, 0);

3. Acknowledge that ide-cd.c was not meant to work as in (2) and search 
for another mechanism. Where?

(1) would unnecessarily duplicate the drive's state. I'd rather do (3).

So far, the (2) works well, but how bad is it?
I'd greatly appreciate any critical feedback.

TIA,
Piotr Muszynski

-
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/