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]

Date:	Fri, 14 Oct 2011 17:38:26 +0200
From:	Markus Rechberger <mrechberger@...il.com>
To:	James Courtier-Dutton <james.dutton@...il.com>
Cc:	Valdis.Kletnieks@...edu, 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 10:51 AM, James Courtier-Dutton
<james.dutton@...il.com> wrote:
> On 14 October 2011 07:23, Markus Rechberger <mrechberger@...il.com> wrote:
>> 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.
>>
> Here is what I think the actual situation is.
> Your transfers over the USB are done in 512 Bytes chunks.
> If the device wishes to send 512 bytes, it sends one chunk.
> If the device wishes to send 513 bytes, it sends only one chunk,
> missing one byte.
> if the device wishes to send 1023 bytes, it sends only one chunk,
> missing 511 bytes.
> if the device wishes to send 1024 bytes, it sends two chunks, missing 0 bytes.
> So, the device is sending 1 too few chunks unless the bytes size
> exactly matches the chunk size * n.
> Another constraint is the device sends multiples of 188 bytes.
> So, unless we can find a lowest common multiple of 188 and 512, there
> is no transfer size that will work with this device. The LCM is 24064
> and this is the only value that will work with this device.
>
> Conclusion:
> The hardware on the Linux PC and the kernel on the Linux PC are
> working correctly.
> Your external USB device has an off-by-one error in its
> hardware/embedded software and the hardware/embedded software
> manufacturer is not prepared to fix it.
>
> Workaround in software: Increase MAX from 16384 to 24064 or above.
>
> My own feeling, throw away this faulty bit of hardware and use a different part.
> The hardware is not compatible with USB standards.
>

I agree with that one, and think this conclusion comes closest to the
real issue.
I can imagine that the chip fifo has some issues with that one.
However the device has been tested for a long time without turning to
corrupted data so
the only issue remaining is the buffer alignment.

Thanks for having a look at all that, I wish all requests would have
that kind of review, instead
of "I don't believe you, not acceptable, not right solution at all"

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