linux-kernel - Re: [Patch] Increase USBFS Bulk Transfer size

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: <CA+O4pC+8SbRqRz2uEnG_JkWcPmV_rCsy1zksHYsCk9HKduZRaA@mail.gmail.com>
Date:	Fri, 14 Oct 2011 08:23:10 +0200
From:	Markus Rechberger <mrechberger@...il.com>
To:	Valdis.Kletnieks@...edu
Cc:	James Courtier-Dutton <james.dutton@...il.com>,
	USB list <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, Greg KH <gregkh@...e.de>,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [Patch] Increase USBFS Bulk Transfer size

On Fri, Oct 14, 2011 at 7:47 AM,  <Valdis.Kletnieks@...edu> wrote:
> On Fri, 14 Oct 2011 05:42:44 +0200, Markus Rechberger said:
>
>> The inflexible device which uses 24064 bytes works with all other
>> Operating systems by using that value
>> and gives exactly the same results with other transfer sizes than that.
>
> -ENOPARSE.  If it's inflexible,

the particular device in question is inflexible yes.

> how did you get results for other transfer
> sizes?

other transfer sizes are related to another more flexible device, but that
device has some hardware register to modify the needed transfer buffer size.

> And if other transfer sizes give exactly the same results, why can't you
> just use those instead?
>

other transfer sizes for the device with the fixed transfer buffer
size give exactly the same result with OSX, meaning that it also
does not work on MacOSX with another size than 24064 bytes.

Final conclusion is still:
1. those people who used to deal with USB with linux in the past never
heard about such an option it seems, fact is that the stream corrupts
the logfiles show up damaged data before it arrives to the application
so on that side bugs in the application would be unrelated. As a
crosscheck I also posted a logfile with valid data.
2. the more flexible device even has hardware registers to modify the
bulk transfer size (maybe it's a timing related issue on the physical
usb bus).
3. if the more flexible device is set to buffers > 16k the data also corrupts
4. the fixed buffer size device does not accept any other values, even
twice that requested buffersize corrupts the data.
5. the patch does not hurt, since devices which request buffer sizes
below 16k will still be handled the same way as they were handled
during the last 10 years, it just allows applications to request
bigger buffers if needed.
6. BOTH of our devices (the flexible one device A, can work with
bigger buffers AND a bigger HW register configuration, device B which
is not so flexible also works flawlessly as seen in the video).

I'm repeating myself over and over here.

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