linux-kernel - Re: [PATCH] Fix Corruption issue in USB ftdi driver drivers/usb/serial/ftdi

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+Y=x3msn2uFf+WWE9eU2Su6zDNkbpJUN3w_Vi0671DA3tRsBQ@mail.gmail.com>
Date:	Sat, 29 Oct 2011 07:25:21 +1100
From:	Andrew Worsley <amworsley@...il.com>
To:	Uwe Bonnes <bon@...ktron.ikp.physik.tu-darmstadt.de>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>,
	Alan Cox <alan@...ux.intel.com>,
	Johan Hovold <jhovold@...il.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix Corruption issue in USB ftdi driver drivers/usb/serial/ftdi_sio.c

On 28 October 2011 21:50, Uwe Bonnes
<bon@...ktron.ikp.physik.tu-darmstadt.de> wrote:
>>>>>> "Andrew" == Andrew Worsley <amworsley@...il.com> writes:
>
>    Andrew> ftdi_set_termios() is always setting the baud rate and data bits
>    Andrew> and parity on every call. When called while characters are being
>    Andrew> transmitted can cause the FTDI chip to corrupt the serial port
>    Andrew> bit stream by stalling the output half a bit during the output
>    Andrew> of a character.  Simple fix by skipping this setting if the baud
>    Andrew> rate/data bits/parity are unchanged.
>
>    Andrew> Signed-off-by: Andrew Worsley <amworsley@...il.com> ----
>
>    Andrew> This bug was observed on 2.6.32 kernel (this patch is ported to
>    Andrew> latest kernel for ease of review).  Using a FTDI USB serial chip
>    Andrew> at 38400 repeatedly generating output by running a simple
>    Andrew> command such as "uname -a" or "echo Linux" gives occasional
>    Andrew> corruption on the output
>
>    Andrew> ...
>    >> echo Linux
>    Andrew> L�3u=nux
>
> Could you please give a more specific receipe to reproduce the bug. Running
> with an adapter with TX/RX shorted at "stty -F /dev/ttyUSB0" 38400", several
>> uname -a /dev/ttyUSB0
> runs gave no artifact in a "seyon -modem /dev/ttyUSB0" console.
>
> Doing
>> uname -a /dev/ttyUSB0
> in one xterm and receiving with
>>cat /dev/ttyUSB0
> in another xterm gives lot of repeated lines in the receiving terminal. But
> I have the same behaviour with /dev/ttyS0 on a real serial port on the
> mainboard.
>
> Otherwise, shouldn't all control transfers to the FTDI be only done with the
> tx buffer in the FTDI empty? I guess the RX buffer is not affected by some
> change. But this is something to be done with great knowledge...
>
Thank you for your testing efforts. In a sense I am not surprised that
an obvious attempt at reproduction doesn't show it as I would have
thought this bug would have been found long ago if it
did. At the moment the best I can do is describe my configuration and
invite requests for details on additional fields that you think
important.

We use the ftdi chip to provide a serial console so the program I am
running on it is
/sbin/getty -L ttyUSB0 38400. I can't give you the exact stty settings
the defaults set up as I
am at home but ixon was set but clearing it didn't help.

My key detective was to configure CONFIG_USB_MON and look at the
requests going to the port.
There were always 3 Control requests after each carriage return which
set speed/baud rate/flow control which seemed kinda crazy.

Perhaps it was something to do with the prompt which had an escape
sequence in it as other people noticed that playing with the delay of
the prompt could clear it. Alternatively the more modern kernel may
not illustrate the same issue - due to some fix that avoids or
minimises  the repeated calls of ftdi_set_termios() ?

I suspect the configuration of the tty line is critical and is
something I don't understand as it appears to be constantly adjusting
the settings but only changing the flow control.I don't have the exact
settings in front of me so from memory it appeared to be cycling
through

IXON, IXOFF and may be one other perhaps IXANY or possibly IUCLC?

If people are interested in any particular details I can send you
them, next week. Including
stack traces, CONFIG_USB_MON traces, screen shot of CRO with corrupted
character + other requested
info

But what I don't understand is the logic that drives
ftdi_set_termios() repeated calls with the flow control changes. I
would appreciate an explanation of this and others might be interested
in this if they are trying to optimise the kernel on serial I/O.

Even if such constant calling is justified (some how XON/XOFF is being
implemented?) I think it should be harmless (and more efficient) not
to skip setting the BAUD rate and other data parameters which is a
significant amount of work. And in my case this extract work appears
to be
glitch the FTDI chip.

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