From: Peter Hurley <peter@hurleysoftware.com>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
Valerio Vanni <valerio.vanni@inwind.it>
Subject: Re: [PATCH 1/2] serial: core: Don't drop DTR if system console
Date: Tue, 10 Jun 2014 08:30:45 -0400 [thread overview]
Message-ID: <5396FA75.8020400@hurleysoftware.com> (raw)
In-Reply-To: <20140610120136.2c2cb881@alan.etchedpixels.co.uk>
On 06/10/2014 07:01 AM, One Thousand Gnomes wrote:
>> This patch only affects the line state if the last tty reference is closed
>> or the tty is hung up by software (like on controlling process exit).
>> In this case, any login session is already dying, and it would not be possible
>> to hijack a live session. A successful re-login is still required.
>
> It breaks the other direction - yes sorry.
>
>> Notwithstanding what I wrote above, this patch does change behavior
>> with remote consoles, which may be unacceptable.
>
>> For example, if the remote user logs out, the current behavior hangs up
>> the modem (if HUPCL), whereas the patch behavior just presents a new
>> login prompt.
>
> which means the modem will probably no longer answer calls.
I would expect the vast majority of modems to be configured to hang-up
after carrier loss (when the remote user hangs up).
I think the more significant impact is that killing the login process
(by the sysadmin) wouldn't disconnect a malicious user (but would still
force the re-login). I see this as more nuisance value than any
realistic DoS.
>> So yeah, I agree; this patch should be dropped.
>
> Possibly we should also fix this the other way in tty_port_shutdown,
> which does wrongly skip dtr/rts handling of consoles.
>
> As far as I can see providing HUPCL is clear the desired console
> behaviour for most situations with a remote console link is obtained.
I agree that serial core and tty port should handle the console
identically, so if the serial core defaults are the expected behavior,
then, yes, tty_port_shutdown() should not skip dropping dtr/rts.
However, a console on USB tty is much more likely to be local, rather
than remote, so changing dtr/rts handling could impact these setups.
Since the termios c_cflag is inherited from the console, what about adding
new flow control flag decodes to uart_set_options(); eg.,
'r' = CRTSCTS | HUPCL /* existing */
'R' = CRTSCTS | !HUPCL
default = !CRTSCTS | HUPCL
'd' = !CRTSCTS | !HUPCL
?
Regards,
Peter Hurley
prev parent reply other threads:[~2014-06-10 12:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-30 9:53 serial console does not wake from S3 suspend Valerio Vanni
2014-06-04 14:16 ` [PATCH 1/2] serial: core: Don't drop DTR if system console Peter Hurley
2014-06-04 14:16 ` [PATCH 2/2] serial: core: Preserve termios c_cflag for console resume Peter Hurley
2014-06-04 14:22 ` Greg Kroah-Hartman
2014-06-04 14:46 ` Peter Hurley
2014-06-04 14:48 ` Peter Hurley
2014-06-04 23:31 ` Valerio Vanni
2014-06-05 8:58 ` Valerio Vanni
2014-06-04 14:22 ` [PATCH 1/2] serial: core: Don't drop DTR if system console Greg Kroah-Hartman
2014-06-04 14:36 ` Peter Hurley
2014-06-09 13:08 ` One Thousand Gnomes
2014-06-10 1:20 ` Peter Hurley
2014-06-10 11:01 ` One Thousand Gnomes
2014-06-10 12:30 ` Peter Hurley [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5396FA75.8020400@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=valerio.vanni@inwind.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).