linux-kernel - Re: tty TTY

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]

Date:	Wed, 4 Jan 2012 16:27:45 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	markh@...pro.net
Cc:	Linux-kernel <linux-kernel@...r.kernel.org>,
	Mark Hounschell <dmarkh@....rr.com>
Subject: Re: tty  TTY_HUPPED anomaly

> But what has carrier dropping got to do with an TIOCSETD ioctl. For that 

When the carrier is dropped and HUPCL is set then the tty is disconnected
from the physical interface. It's specified behaviour and required for
security. So by the time you go to issue the TIOCSETD you are no longer
connected to the tty. That may well just be a timing change.

> What can be done to prevent tty_hangup from being called after opening 
> the port? And if this is really supposed to happen, why does it not 
> always happen?

It should only happen if the carrier is dropped.

> Even if the first thing I do after opening the port is to clear HUPCL 
> and set CLOCAL, this still randomly happens the first time I open the 
> port after booting.

I'd expect the behaviour to either be

carrier high, stays high - open works, no hangup events seen

or

carrier low, stays low - open blocks, but open with O_NDELAY works,
hangup events not seen.

It's the act of the drop which is a hangup not the presence of low
carrier if I remember the spec properly. The Synclink GT correctly does
this as far as I can tell (I have no hardware or docs for it) but the
code indicates that the hardware reports changes and it acts on them
properly (checking CLOCAL etc).

I would guess (given the distro change is the trigger) that you've got a
SuSE problem not a kernel one. The kernel behaviour and code looks
correct. My guess therefore is that newer SuSE is running stuff in the
boot which is probing serial ports and messing with the carrier wrongly
and in ways it didn't use to. That would fit the fact that something
similarly broken has apparently also appeared in the Fedora user space
bootup.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/