linux-kernel - Re: Strange output on the console

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: <20220225122546.GB18720@1wt.eu>
Date:   Fri, 25 Feb 2022 13:25:46 +0100
From:   Willy Tarreau <w@....eu>
To:     David Laight <David.Laight@...lab.com>
Cc:     "'Steven Rostedt'" <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        John Ogness <john.ogness@...utronix.de>
Subject: Re: Strange output on the console

On Fri, Feb 25, 2022 at 11:11:49AM +0000, David Laight wrote:
> > > But the earlier output doesn't have many different characters in it.
> > > Which is typical of the baud rate being wrong.
> > 
> > I don't think so, here's the beginning of the capture:
> > 
> >   Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> >   0SI 15Nto
> >   LgtAsri[dnei00ieC nm
> >   i:0eom:Soce
> >   [ad000Ade s:ii SSLtbueludAis002h00 1)ASrPn
> >   Ars004h00 7ARrPn
> > 
> > All of these chars are within the printable set, so there's a probability
> > of ~37% per char, so even for a short string of 9 chars like the first
> > line, that's a 0.01% chance of it respecting the set. That's why for me
> > it definitely doesn't correspond to a baud rate issue. With wrong baud
> > rates you get lots of garbage in the full 8-bit range.
> > 
> > In addition there are even upper case at the beginning of the lines which
> > probably correspond to the ones that are printed on these lines.
> 
> Ok, that bit is probably output after the fifo is disabled.
> 
> But a few lines later you get:
> 
> TntiTet_TetkT t:TetyTvt:TntaTttTet TeteTvtnTntnTvtnT teT teTettTettKTeteTttnTnteTttaTttaTetKTttOTet:TvtnTvtltTntw Tnt:T tOTvt_Tnt:TvtKTntnT tsTvtsTttsTttsTttosTvtotTtt:TntrTntOTet T ttTvtKT tKT teTnttTettTntaTntdTttaT taTeteT tTtt TttrTntlTvt:TetkT tTtttTnteTttOTetkTvtsTeteT tlTttoTntoTetpTvtpTetsTvtvTvteTntOTet
> TttTetsTetsTntsTetKT t TttiTttT tnT tOTnt_TttrTtttTntKTetOTtteTnt:T tKTttpTvdoT dxTvdnTtd TedtTedoTvdiTedaTedT d Ttd:TedtTtd TeddTvdKTediTndgTednTtdgTtd TedKT snTesTtsOTesKTnstTvsOTvsTnsKTvs:Tts:TesTvs:Tns Tes T sdTts TtsoTesOTtslTesnTesKTesOTns
> TnsTesOT s T sKTesOT sKTvsOTtsTtsKTtsT sKTesTesKT sKTesOT siT stTnsaTvsaTesKTnsOT s
> TesKTnsT s TvsKTeslT sOTesT sKTtseTnseTvs_Tts_T sOTes TnsOT s T spTespTesdTesdTeseTtseTeseTt_rTe_rTv_oTes:T s:Tes:TnfwOTvfrKT fwT frTefpuTefpKTefpTvf:TnsOTvsOTnsoTvs Tvs TvsTtssTnsT sKTesTnsTvsTtsoTesmTnsgTesiTeslTtsTvsKTnsTvsOTtsT s_Tnsu
> 
> which really doesn't have enough different characters in it to be a fifo problem.
> That looks like a UART struggling to find valid start and stop bits
> on a continuous data stream that doesn't match the baud rate.
> 
> It may also be that whatever 'terminal' is being used is masking off the 0x80 bit.

That could be one option I thought about but still, that sounds quite
suspicious. You don't even get any #!:$/ etc. Or maybe the UART is
configured in 6-bit mode (most 16550 support 5-8 bits), and maybe even
the stop bit and/or parity participates.

> Another possibility is that the count of characters is about right.
> But the receiver is misaligned on the 10 bit async characters.
> Because these is no line idle, it never synchronises properly.
> ISTR a real async terminal behaving that way.
> But I think that gives a much wider range of characters - just the wrong ones.
>
> There is also a third error pattern:
> ^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[
> which might be an 'even more wrong' baud rate.

This one just looks like the Up arrow, that Steven might have pressed at
some point during the capture.

> So maybe we are both right - for different bits of the error.

:-)
... and Steven having fun reading our proposals after having made this
up entirely in preparation of the next April's fool :-)

Willy