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: <20220225103239.GA18720@1wt.eu>
Date:   Fri, 25 Feb 2022 11:32:39 +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 10:11:43AM +0000, David Laight wrote:
> From: Willy Tarreau
> > Sent: 25 February 2022 06:37
> > 
> > On Fri, Feb 25, 2022 at 06:12:35AM +0000, David Laight wrote:
> > > From: Steven Rostedt
> > > > Sent: 25 February 2022 04:01
> > > >
> > > > I've been noticing that my tests have been spitting out strange output on
> > > > the console. It would happen at boot up and then clear up. It looks like
> > > > something screwed up with the serial timing.
> > > >
> > > > Attached is a dmesg of one of my test runs as an example.
> > > >
> > > > I've noticed this on both 32 bit and 64 bit x86.
> > > >
> > > > I haven't had time to look deeper into this, but I figured I let you know
> > > > about it.
> > > >
> > > > And it always seems to happen right after:
> > > >
> > > >   Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> > > >
> > > > Maybe this is a serial issue and not a printk one? :-/
> > >
> > > Looks very much like the serial baud rate is being reset.
> > 
> > I don't think it's the baud rate, characters are still readable, it
> > looks more like a fifo being too short and causing lots of chars to
> > be dropped.
> 
> Just before it recovers there is this output:
>     ATaitoscic nitahi tuPiet mfba Ae:   aD nCt AH0 nP0
> That is probably 'fifo not enabled'.
> 
> 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.

Willy