linux-kernel - Re: [PATCH v2 2/7] serial: qcom-geni: fix shutdown race

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: <ZwaO0hCKdPpojvnn@hovoldconsulting.com>
Date: Wed, 9 Oct 2024 16:10:26 +0200
From: Johan Hovold <johan@...nel.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Johan Hovold <johan+linaro@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jirislaby@...nel.org>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konradybcio@...nel.org>,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org, stable@...r.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v2 2/7] serial: qcom-geni: fix shutdown race

On Thu, Oct 03, 2024 at 11:30:08AM -0700, Doug Anderson wrote:
> On Tue, Oct 1, 2024 at 5:51 AM Johan Hovold <johan+linaro@...nel.org> wrote:
> >
> > A commit adding back the stopping of tx on port shutdown failed to add
> > back the locking which had also been removed by commit e83766334f96
> > ("tty: serial: qcom_geni_serial: No need to stop tx/rx on UART
> > shutdown").
> 
> Hmmm, when I look at that commit it makes me think that the problem
> that commit e83766334f96 ("tty: serial: qcom_geni_serial: No need to
> stop tx/rx on UART shutdown") was fixing was re-introduced by commit
> d8aca2f96813 ("tty: serial: qcom-geni-serial: stop operations in
> progress at shutdown"). ...and indeed, it was. :(
> 
> I can't interact with kgdb if I do this:
> 
> 1. ssh over to DUT
> 2. Kill the console process (on ChromeOS stop console-ttyMSM0)
> 3. Drop in the debugger (echo g > /proc/sysrq-trigger)

Yeah, don't do that then. ;)

Not sure how your "console process" works, but this should only happen
if you do not enable the serial console (console=ttyMSM0) and then try
to use a polled console (as enabling the console will prevent port
shutdown from being called). That should probably just be disallowed.

The console code, and the polled console code bolted on top, is a bit of
a hack so corner cases like this are to be expected.

When the polled console code was introduced it was claimed that it would
have "absolutely zero impact as long as CONFIG_CONSOLE_POLL is
disabled". Perhaps I'm reading too much into it, but that statement is
clearly ignoring the maintenance cost...

Johan