linux-kernel - Re: [PATCH v2 2/3] usb: gadget: file_storage: Make CD-ROM emulation work with Mac OS-X

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]

Message-ID: <4D88AF6F.4050508@nokia.com>
Date:	Tue, 22 Mar 2011 16:17:19 +0200
From:	Roger Quadros <roger.quadros@...ia.com>
To:	<stern@...land.harvard.edu>
CC:	<gregkh@...e.de>, <sshtylyov@...sta.com>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/3] usb: gadget: file_storage: Make CD-ROM emulation
 work with Mac OS-X

Hi,

On 03/21/2011 12:59 PM, ext Roger Quadros wrote:
> @@ -1703,18 +1705,21 @@ static int do_read_toc(struct fsg_dev *fsg, struct fsg_buffhd *bh)
>   		return -EINVAL;
>   	}
>
> -	memset(buf, 0, 20);
> -	buf[1] = (20-2);		/* TOC data length */
> -	buf[2] = 1;			/* First track number */
> -	buf[3] = 1;			/* Last track number */
> -	buf[5] = 0x16;			/* Data track, copying allowed */
> -	buf[6] = 0x01;			/* Only track is number 1 */
> -	store_cdrom_address(&buf[8], msf, 0);
> +	format = fsg->cmnd[2]&  0xf;
> +	/*
> +	 * Check if CDB is old style SFF-8020i
> +	 * i.e. format is in 2 MSBs of byte 9
> +	 * Mac OS-X host sends us this.
> +	 */
> +	if (format == 0)
> +		format = (fsg->cmnd[9]>>  6)&  0x3;
>
> -	buf[13] = 0x16;			/* Lead-out track is data */
> -	buf[14] = 0xAA;			/* Lead-out track number */
> -	store_cdrom_address(&buf[16], msf, curlun->num_sectors);
> -	return 20;
> +	ret = fsg_get_toc(curlun, msf, format, buf);
> +	if (ret<  0) {
> +		curlun->sense_data = SS_INVALID_FIELD_IN_CDB;
> +		return -EINVAL;
> +	}
> +	return ret;
>   }


I have a question here.

The host can request us to send less or more than the actual TOC size, since it 
has no clue how big it is.
e.g. Linux host requests us to send only 12 bytes even though our formatted TOC 
length is 20. In this case should we return fsg->data_size_from_cmnd instead of 
actual TOC length?

e.g. Mac requests us to send 65534 bytes but our RAW TOC length is 37.
The file storage driver seems to be zero padding our data response. So we 
respond with 65534 bytes, 37 of TOC and remaining zero padded.

Can we do something like this to avoid unnecessary zero padded transfers?

         ret = fsg_get_toc(curlun, msf, format, buf);
         if (ret < 0) {
                 curlun->sense_data = SS_INVALID_FIELD_IN_CDB;
                 return -EINVAL;
         } else if (ret > fsg->data_size_from_cmnd) {
                 ret = fsg->data_size_from_cmnd;
         } else {
                 fsg->residue = ret;
         }
         return ret;

-- 
regards,
-roger
--
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/