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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Oct 2011 18:12:42 +0200
From:	Markus Rechberger <mrechberger@...il.com>
To:	Chris Friesen <chris.friesen@...band.com>
Cc:	Alan Stern <stern@...land.harvard.edu>, Greg KH <gregkh@...e.de>,
	USB list <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Patch] Increase USBFS Bulk Transfer size

On Thu, Oct 13, 2011 at 6:01 PM, Chris Friesen
<chris.friesen@...band.com> wrote:
> On 10/13/2011 09:19 AM, Markus Rechberger wrote:
>>
>> On Thu, Oct 13, 2011 at 4:58 PM, Alan Stern<stern@...land.harvard.edu>
>>  wrote:
>
>>> This is very interesting.  There are only two things that could be
>>> happening: Either the device sends different data during the two tests,
>>> or there's a bug in the kernel.
>
>> Before that I insist that this patch will go into the kernel (I know
>> that sounds ridiculous but so far I did everything
>> you requested me to do), I clearly pointed out that we even have hardware
>> specs which can influence the transfer buffer. The patch does not hurt
>> and makes the device work.
>
> That makes no sense.  If there's a bug in the hardware we likely don't want
> to make global changes to work around it--a more targeted fix may be more
> appropriate.
>

Did you read the part about that we have some hardware which can do
some settings
in hardware to affect the transfer buffer? Even that part is not clear
how it can affect the
transfer for the usb subsystem.

Why on earth should things be done differently than with all other
operating systems?

> If there is a bug in the kernel, why would we want a bandaid patch that just
> happens to make it work rather than a true fix?
>

In silicon? Are you going to tape out another one for it?
First priority is that the device can work and be sold, my last
priority is that requested academic research (as we are not
the design house for the particular IC), I'm willing
to support it if my request is fulfilled, the demo videos are online
and show that it works with increasing the maximum allowed buffersize.

And about the particular device the boundaries are just around 7000
bytes off and people are screaming about that? Sorry this is just like
in kindergarden 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/