linux-kernel - Re: Gaps in logs while using usb-serial as a 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: <2023103003-defection-recess-cf49@gregkh>
Date:   Mon, 30 Oct 2023 09:30:15 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     ariel marcovitch <arielmarcovitch@...il.com>
Cc:     johan@...nel.org, linux-usb@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Gaps in logs while using usb-serial as a console

On Mon, Oct 30, 2023 at 10:15:30AM +0200, ariel marcovitch wrote:
> > Please realize that usb-serial console was the result of me loosing a
> > drunken bet.  It's amazing it works at all.  For "fake" devices like
> LOL your drunken bet was quite helpful to some people
> Because modern PCs come without a serial port, I wanted to use it to
> see early logs on my crashing kernel without having to use printk
> delay and things like that.
> I'm curious as to how kernel people debug PCs in general...

We use a usb debug port connection (it's a special cable).

> In any case, the usb-serial setup was quite weird as it required two
> usb-serial and a gender changer

Yes, that's normal.

> > this, that use the generic usb-serial code, yes, you will have overruns
> > and other problems, that's just part of how it works (i.e. not well.)
> >
> > For something like qemu, please use a real console, like the serial port
> > (i.e. a fake serial port), not the fake usb-serial port.
> Yeah I was just using it to demonstrate the problem (I agree it is
> quite weird to use usb-serial as a console for qemu)
> I experienced the same problem with a real usb-serial device, then I
> tried to use emulation so I can debug it more easily

Which real usb-serial device?  That matters as it's up to the individual
driver to handle the flow control properly.

> > So this is "working as designed" in that it wasn't designed at all and
> > again, it is a miracle any data is flowing there at all :)
> I see...
> However it may be possible to fix it without much effort, so why not?
> Something like checking the return value for the console's write
> function seems reasonable to me anyway...

But overflows for buffers can not be handled by consoles like this

> Besides, don't other types of consoles have the same problem (being
> initialized late, getting a lot of data, losing some of it)?

Yes, they do have that problem, this is not unique.  You can just see it
very easily when using the generic usb-serial driver as there is almost
no buffering at all in it other than what the tty layer provides.

Adding larger buffers can help with this, but where do you stop?  What
is the proper buffer size to always use?

Overall, if you are going to be doing lots of debugging of early-boot
and console logs, I recommend getting a usb debug cable instead, sorry.
usb-serial console is just "best effort" and we're happy that any data
flows out of the thing at all :)

thanks,

greg k-h